Thanks! My wife had a fun weekend away with her friends this weekend. After the kiddos went to bed, I got to pretend I was 20 again and worked until 2 AM or so. :) We're really, really close on the macOS packaging revamp.
Adam On Mon, Apr 30, 2018 at 2:48 PM, Wayne Stambaugh <[email protected]> wrote: > Adam, > > Looks like this is the culprit: > > @@ -431,7 +431,7 @@ if( NOT APPLE ) > else() > # everything without leading / is relative to CMAKE_INSTALL_PREFIX. > # CMAKE_INSTALL_PREFIX is root of .dmg image > - set( KICAD_BIN ${CMAKE_INSTALL_PREFIX} > + set( KICAD_BIN "." > CACHE PATH "Location of KiCad binaries." FORCE ) > > This is inside the macos specific install code. My guess is Simon did a > grep and replaced all of the offending code and missed that this was > macos specific. I just pushed the change that restored the original > behavior. > > Cheers, > > Wayne > > On 4/30/2018 2:58 PM, Adam Wolf wrote: >> Hi all, >> >> I am seeing build issues on macOS today, and they go away when I >> checkout the commit before the CMAKE_INSTALL_PREFIX change. >> >> I am deep into my own branch right now, but can someone doublecheck >> this is guarded to not make changes in macOS? I skimmed the patch and >> it looked like it wouldn't, but I could use another set of eyes while >> I finish my other KiCad work. I am pretty sure BundleUtilities uses >> CMAKE_INSTALL_PREFIX and matches the error messages I'm seeing. >> >> Sorry folks, I hope this isn't just noise. >> >> Adam >> >> On Mon, Apr 30, 2018 at 10:02 AM, Simon Richter >> <[email protected]> wrote: >>> Hi Nick, >>> >>> On 30.04.2018 16:35, Nick Østergaard wrote: >>> >>>> @Simon, does MAKE_INSTALL_DATADIR work for gnu stow? If so, I guess it >>>> is safer to use that variable, as we do elsewhere. >>> >>> The problem I'm addressing with my patch is configure time vs. install >>> time path resolution -- if you explicitly use the variable there, you >>> generate an absolute path at configure time, and it remains absolute >>> during installation, while a relative path has a variable reference >>> implicitly prepended to it which is resolved at install time. >>> >>> So using CMAKE_INSTALL_DATADIR wouldn't work, what is needed is some way >>> to say "relative to whatever the variable is set to during installation". >>> >>> The traditional way to install with stow is to configure for a prefix of >>> /usr/local, then override that as /usr/local/DIR/kicad for installation >>> and symlink the files into the /usr/local tree -- that way, if you have >>> compiled-in paths, they will use the /usr/local prefix, so the software >>> will only be a tiny bit confused if it expects its data files not to be >>> symlinks). >>> >>> This is very close to what we do with DESTDIR (which is what most >>> distros use), but works without an extra renaming step. >>> >>> Simon >>> >>> >>> _______________________________________________ >>> Mailing list: https://launchpad.net/~kicad-developers >>> Post to : [email protected] >>> Unsubscribe : https://launchpad.net/~kicad-developers >>> More help : https://help.launchpad.net/ListHelp >>> >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~kicad-developers >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp >> > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : [email protected] > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
