kicad-developers team mailing list archive

[Adam Wolf <adamwolf@xxxxxxxxxxxxxxxxxxxx>]

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 <stambaughw@xxxxxxxxx> 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
>> <Simon.Richter@xxxxxxxxxx> 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     : 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