kicad-developers team mailing list archive

[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
>