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