kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

I'm not opposed to this patch if it's merely a short tern solution to a
larger problem.  I would rather macos support STEP export for v5.
Hopefully a cleaner long term solution can be found as part of the v6
development as the patch adds some rather ugly #ifdef/#endif code.

Cheers,

Wayne

On 06/15/2018 10:13 AM, Seth Hillbrand wrote:
> Hi Adam/Bernhard-
> 
> Thanks for the excellent background and what looks like a good plan
> during v6.  If I understand correctly, the thought is that this patch is
> temporary for v5 and will be addressed with the rest of the paths during v6.
> 
> If that is correct, does anyone have objections to this patch for MacOS?
> 
> -S
> 
> Am Fr., 15. Juni 2018 um 05:04 Uhr schrieb Adam Wolf
> <adamwolf@xxxxxxxxxxxxxxxxxxxx <mailto:adamwolf@xxxxxxxxxxxxxxxxxxxx>>:
> 
>     Thanks Bernhard for the clear responses.
> 
>     1) The only current issue with signing is that the standalone
>     launchers both live inside and outside the bundle.  With all the
>     work I've done on packaging since V4, we can now give kicad.app a
>     valid signature, but there's no way to sign the subbundles that
>     allows them to be both external and internal to KiCad.app.
> 
>     2) I have a few ideas for how to make it work for V6, but my primary
>     one is the same as yours.  If kicad.app opened .pro files, but also
>     .schs and .kicad_pcbs and other files, and used filenames or
>     something in order to pick which mode to open up in, the signing
>     problem goes away. As soon as V5 is out, I'm planning on opening a
>     discussion on it here.
> 
>     3) Thanks so much for your help on KiCad!
> 
>     Regarding this patch, I think there are a few options.  We can do
>     nothing, fix-up validation so you can only export STEP from either
>     standalone or kicad.app.  We could make make some logical functions
>     like isStandaloneExecutable and GetPathToKiCad or something like
>     that.  We could add more comments, maybe even aiming people at this
>     discussion?  We could rewrite it in a different way.  We could fix
>     it in packaging--we could copy kicad2step to multiple directories,
>     and make it work that way.  I can also leave the patch in the
>     packaging scripts, but that leaves this broken for anyone who
>     doesn't use them.
> 
>     Some of these I like, others I don't, but no matter which one we
>     choose, as soon as V5 is out the door, I'm taking it out.  I don't
>     want it to be egregiously bad, since it'll probably live in the
>     stable release for a while, but at the same point, I'm not married
>     to any of the ideas.
> 
>     Thanks everyone for the discussion.  Discussions like this help
>     elucidate parts of the code that few people touch, and that helps
>     make KiCad even better. We are really close to the best Kicad
>     release yet!
> 
>     Adam Wolf
> 
>     On Fri, Jun 15, 2018 at 3:20 AM Bernhard Stegmaier
>     <stegmaier@xxxxxxxxxxxxx <mailto:stegmaier@xxxxxxxxxxxxx>> wrote:
>     >
>     > And, for the path stuff…
>     >
>     > I think it needs a complete cleanup.
>     > There are paths spread all over the code (directly or indirect by
>     putting some path fragments together)… for plugins, templates,
>     user-folders, help files, etc.
>     > Worse, all those places are also full of platform #ifdef’s which
>     doesn’t make it more easy…
>     >
>     > I think it shouldn’t be allowed to have paths anywhere in the code.
>     > Instead, everything should be in some central configuration class
>     where they can be configured in a consistent way for all platforms.
>     > I guess there shouldn’t be that much paths involved, otherwise no
>     user will understand where to put things anyway (sometimes I feel
>     that exactly this is happening at the moment).
>     >
>     > I did cleanup some things for macOS when I did the packaging stuff
>     long ago (only use things like GetOSXKicadDataDir() from common.cpp
>     where appropriate).
>     > But, I didn’t understand kicad and its intended (folder)
>     structures (especially for Linux/Windows) enough at that point in
>     time, so I gave up…
>     >
>     >
>     > Regards,
>     > Bernhard
>     >
>     > > On 15. Jun 2018, at 06:58, Adam Wolf
>     <adamwolf@xxxxxxxxxxxxxxxxxxxx
>     <mailto:adamwolf@xxxxxxxxxxxxxxxxxxxx>> wrote:
>     > >
>     > > The symlinked subbundles date back to the original KiCad mac
>     packaging
>     > > work, before V4 came out.  There is a pretty massive amount of
>     code in
>     > > our CMake and KiCad already that support how this works.  I think
>     > > Bernhard was the main driver of this work, but I am not sure.
>     > > Specifically, the relative paths are already in KiCad source at
>     least
>     > > 2 other time.  I am not sure why kicad2step got added the way it
>     did.
>     > > I was not involved.
>     > >
>     > > Removing all of the symlinked subbundles is actually part of my V6
>     > > work, because KiCad.app is not signable until it doesn't have these,
>     > > but that's not a small undertaking.
>     > >
>     > > Maybe Bernhard can weigh in more?
>     > >
>     > > Adam Wolf
>     > > On Thu, Jun 14, 2018 at 10:27 PM Seth Hillbrand
>     > > <seth.hillbrand@xxxxxxxxx <mailto:seth.hillbrand@xxxxxxxxx>> wrote:
>     > >>
>     > >>
>     > >> Hi Adam-
>     > >>
>     > >> Is there a reason why the kicad2step is installed in the KiCad
>     base application rather than the pcbnew application?  I didn't look
>     into this in depth but I wonder if we can avoid code dealing with a
>     specific packaging scenario?
>     > >>
>     > >> Alternatively, we might put a variable in CMAKE defining where
>     these applications are installed and reference that in the code. 
>     Hard-coding the relative paths feels like asking for trouble.
>     > >>
>     > >> Thoughts?
>     > >> -S
>     > >>
>     > >>
>     > >> Am Do., 14. Juni 2018 um 05:41 Uhr schrieb Adam Wolf
>     <adamwolf@xxxxxxxxxxxxxxxxxxxx <mailto:adamwolf@xxxxxxxxxxxxxxxxxxxx>>:
>     > >>>
>     > >>> Yeah, this is actually all over the source code.  I'm starting
>     to collect a list of them for V6... but I shall say no more until
>     I'm ready with V5 :)
>     > >>>
>     > >>> On Thu, Jun 14, 2018, 3:32 AM Nick Østergaard
>     <oe.nick@xxxxxxxxx <mailto:oe.nick@xxxxxxxxx>> wrote:
>     > >>>>
>     > >>>> Ok.
>     > >>>>
>     > >>>> 2018-06-14 9:37 GMT+02:00 Bernhard Stegmaier
>     <stegmaier@xxxxxxxxxxxxx <mailto:stegmaier@xxxxxxxxxxxxx>>:
>     > >>>>>
>     > >>>>> I didn’t test this patch, but… something like a install
>     prefix path is not valid for a bundle.
>     > >>>>> A bundle is a self-contained entity and has no fixed
>     location. You can put it wherever you want.
>     > >>>>> So, everything has to be relative to main binary or bundle
>     location.
>     > >>>>>
>     > >>>>>
>     > >>>>> Regards,
>     > >>>>> Bernhard
>     > >>>>>
>     > >>>>>
>     > >>>>> On 14. Jun 2018, at 08:51, Nick Østergaard
>     <oe.nick@xxxxxxxxx <mailto:oe.nick@xxxxxxxxx>> wrote:
>     > >>>>>
>     > >>>>> It seems a bit strange to be that relative paths like that
>     has to be used, can't some cmake install prefix path be used wheni
>     is a bundle? Is this also how it is done for other parts of kicad?
>     > >>>>>
>     > >>>>> 2018-06-13 4:39 GMT+02:00 Adam Wolf
>     <adamwolf@xxxxxxxxxxxxxxxxxxxx <mailto:adamwolf@xxxxxxxxxxxxxxxxxxxx>>:
>     > >>>>>>
>     > >>>>>> Hi folks!
>     > >>>>>>
>     > >>>>>> This patch is meant to fix a crash Seth found when
>     exporting STEP from
>     > >>>>>> standalone pcbnew on macOS.
>     > >>>>>>
>     > >>>>>> Thanks!  My apologies for having this so late in the
>     cycle.  this is
>     > >>>>>> going to be an amazing release for everyone, especially
>     macOS users!
>     > >>>>>>
>     > >>>>>> Adam Wolf
>     > >>>>>>
>     > >>>>>> _______________________________________________
>     > >>>>>> Mailing list: https://launchpad.net/~kicad-developers
>     > >>>>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>     > >>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>     > >>>>>> More help   : https://help.launchpad.net/ListHelp
>     > >>>>>>
>     > >>>>>
>     > >>>>> _______________________________________________
>     > >>>>> Mailing list: https://launchpad.net/~kicad-developers
>     > >>>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>     > >>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>     > >>>>> More help   : https://help.launchpad.net/ListHelp
>     > >>>>>
>     > >>>>>
>     > >>>>
>     > >>> _______________________________________________
>     > >>> Mailing list: https://launchpad.net/~kicad-developers
>     > >>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>     > >>> Unsubscribe : https://launchpad.net/~kicad-developers
>     > >>> More help   : https://help.launchpad.net/ListHelp
>     > >
>     > > _______________________________________________
>     > > Mailing list: https://launchpad.net/~kicad-developers
>     > > Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>     > > Unsubscribe : https://launchpad.net/~kicad-developers
>     > > More help   : https://help.launchpad.net/ListHelp
>     >
> 
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>