kicad-developers team mailing list archive

[Adam Wolf <adamwolf@xxxxxxxxxxxxxxxxxxxx>]

That is correct.  This is a temporary workaround before some large V6
refactoring (that still needs the details figured out).

Adam
On Fri, Jun 15, 2018 at 9:13 AM Seth Hillbrand <seth.hillbrand@xxxxxxxxx> 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>:
>>
>> 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> 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> 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> 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>:
>> > >>>
>> > >>> 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> wrote:
>> > >>>>
>> > >>>> Ok.
>> > >>>>
>> > >>>> 2018-06-14 9:37 GMT+02:00 Bernhard Stegmaier <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> 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>:
>> > >>>>>>
>> > >>>>>> 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
>> > >>>>>> 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
>> > >>>>>
>> > >>>>>
>> > >>>>
>> > >>> _______________________________________________
>> > >>> 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
>> > >
>> > > _______________________________________________
>> > > 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
>> >