kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #36195
Re: [PATCH] Handle STEP export properly on MacOS when launched from standalone pcbnew.
Adam, does the patch fix STEP export for both kicad.app and standalone pcbnew?
If not, if you like I could try to have a look at the weekend if we can add some check for standalone to get both working for v5 now.
I don’t know exactly, but I think there should be similar stuff in the code already…
Bernhard
> On 15. Jun 2018, at 18:39, Adam Wolf <adamwolf@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> I would even commit to adding a comment saying "Adam says this is
> temporary and should be removed during the V6 development efforts", so
> folks can more easily shame me if it ends up staying around for longer
> than expected :)
>
> Adam
> On Fri, Jun 15, 2018 at 11:34 AM Wayne Stambaugh <stambaughw@xxxxxxxxx> wrote:
>>
>> 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
>>>
>>
>> _______________________________________________
>> 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
Follow ups
References
-
[PATCH] Handle STEP export properly on MacOS when launched from standalone pcbnew.
From: Adam Wolf, 2018-06-13
-
Re: [PATCH] Handle STEP export properly on MacOS when launched from standalone pcbnew.
From: Nick Østergaard, 2018-06-14
-
Re: [PATCH] Handle STEP export properly on MacOS when launched from standalone pcbnew.
From: Bernhard Stegmaier, 2018-06-14
-
Re: [PATCH] Handle STEP export properly on MacOS when launched from standalone pcbnew.
From: Nick Østergaard, 2018-06-14
-
Re: [PATCH] Handle STEP export properly on MacOS when launched from standalone pcbnew.
From: Adam Wolf, 2018-06-14
-
Re: [PATCH] Handle STEP export properly on MacOS when launched from standalone pcbnew.
From: Seth Hillbrand, 2018-06-15
-
Re: [PATCH] Handle STEP export properly on MacOS when launched from standalone pcbnew.
From: Adam Wolf, 2018-06-15
-
Re: [PATCH] Handle STEP export properly on MacOS when launched from standalone pcbnew.
From: Bernhard Stegmaier, 2018-06-15
-
Re: [PATCH] Handle STEP export properly on MacOS when launched from standalone pcbnew.
From: Adam Wolf, 2018-06-15
-
Re: [PATCH] Handle STEP export properly on MacOS when launched from standalone pcbnew.
From: Seth Hillbrand, 2018-06-15
-
Re: [PATCH] Handle STEP export properly on MacOS when launched from standalone pcbnew.
From: Wayne Stambaugh, 2018-06-15
-
Re: [PATCH] Handle STEP export properly on MacOS when launched from standalone pcbnew.
From: Adam Wolf, 2018-06-15