kicad-developers team mailing list archive

[Adam Wolf <adamwolf@xxxxxxxxxxxxxxxxxxxx>]

Hi folks!

A user is having a problem with the latest OS X RC2 release, and I haven't
been able to figure it out.

Quick background:

There is a KiCad package, and a KiCad Extras package.  The KiCad Extras
package has a modules/ directory in it, and it has all the footprints.
It's for offline use.  It also has an fp-table-lib, which uses KISYSMOD to
point at the modules, like this:

  (lib (name Capacitors_SMD)(type KiCad)(uri
${KISYSMOD}/Capacitors_SMD.pretty)(options "")(descr "The way you like
them."))

My builds have DEFAULT_INSTALL_PATH set to /Library/Application
Support/kicad, like I want them to.  I checked the build output, and it
shows:

-- Kicad install dir: </Library/Application Support/kicad>


Great, awesome, exactly like I want it.

On the other hand--we have a user, who newly installed KiCad on his Mac,
and it looks like his KISYSMOD is being set to a path on the build system,
probably CMAKE_INSTALL_PREFIX. (
https://bugs.launchpad.net/kicad/+bug/1426754)  (This was happening
previously, and I started to set DEFAULT_INSTALL_PATH, and things got
better for people after they cleared their preferences.)

As far as I can tell, those defaults are set in common/pgm_base.cpp, and
the only Mac specific ifdef is to not include /share/kicad/ in KISYSMOD's
path. (Which is correct.)

I cleared all my KiCad preferences and reinstalled the same package he did
(as part of testing the RC2, like I do with most significant builds) and
did not have this issue.

The only possible issue I see when looking for DEFAULT_INSTALL_PATH stuff
for OS X is in common/systemdirsappend.cpp, in void SystemDirsAppend(
SEARCH_STACK* aSearchStack ). Instead of adding DEFAULT_INSTALL_PATH, it
uses some OS X specific functions, but those seem to be working fine.

So.  This is happening to a user, and I cannot reproduce it, but I'm
worried about releasing 4.0.0 on OS X without more information.  I know of
30+ installs of 4.0.0 RC2 that *didn't* have this issue for Jimmy, but I
suspect they all had existing preference files.

1) Does anyone have any insight?

2) Should this hold up the 4.0.0 package for OS X?  I have no real qualms
about doing this and then releasing a 4.0.0-2 as soon as this gets figured
out.

3) A possible hack that would fix this could be to change the fp-table-lib
included with the extras package to point to the exact same place as the
symlink--i.e. expand out KISYSMOD.  I actually don't necessarily see a huge
problem with this--if a user wants to install the files somewhere else than
the default package does it, they are probably capable of a search/replace
in a text editor.

I'd rather fix the real issue, but being that I cannot reproduce it after
~3 hours, I'm not sure I want to say "I'm not going to cut a 4.0.0 release
until this is fixed."

Thoughts?

Adam Wolf
Cofounder and Engineer
W&L