parrot_config --dump: libparrot_linkflags, rpath_blib contain references to the build directory if parrot is installed to a DESTDIR first

[ingmar]

If parrot is installed to a staging area (ie DESTDIR=/foo passed to the make install call), then parrot_config --dump contains references to the build directory:

ingmar@cannonball ~/development/git/parrot (git-svn)-[master]- % parrot_config --dump | ack '/var/tmp/paludis/' build_dir => '/var/tmp/paludis/build/dev-lang-parrot-scm/work/parrot-scm' libparrot_linkflags => '-L/var/tmp/paludis/build/dev-lang-parrot-scm/work/parrot-scm/blib/lib -lparrot' rpath_blib => '-Wl,-rpath=/var/tmp/paludis/build/dev-lang-parrot-scm/work/parrot-scm/blib/lib'

"make DESTDIR=/foo install" is quite common for distro packages, so it'd be nice to have a fix for this that I can include in my Exherbo packages.

Regards, Ingmar

[doughera]

Replying to ingmar:

If parrot is installed to a staging area (ie DESTDIR=/foo passed to the make install call), then parrot_config --dump contains references to the build directory:

Actually, it contains references to the build directory whether or not you use DESTDIR.

However, it's not at all clear to me why this is a problem. Those variables are currently intended to only be used in the build directory. See the first few replies to TT #540 for more details.

[heidnes]

Replying to doughera:

Replying to ingmar:

If parrot is installed to a staging area (ie DESTDIR=/foo passed to the make install call), then parrot_config --dump contains references to the build directory:

Actually, it contains references to the build directory whether or not you use DESTDIR. However, it's not at all clear to me why this is a problem. Those variables are currently intended to only be used in the build directory. See the first few replies to TT #540 for more details.

Hm, my take on this is slightly different.

Surely, it must be a goal to make it possible to share one installed parrot between multiple higher-level languages, using a binary package of the shared parrot (I know, e.g. rakudo isn't able to use a shared parrot ... yet). Why should then the installed parrot config contain any references whatsoever to the build directory, which will in this scenario not exist?

[doughera]

Replying to heidnes:

Replying to doughera:

Replying to ingmar:

However, it's not at all clear to me why this is a problem. Those variables are currently intended to only be used in the build directory. See the first few replies to TT #540 for more details.

Hm, my take on this is slightly different. Surely, it must be a goal to make it possible to share one installed parrot between multiple higher-level languages, using a binary package of the shared parrot (I know, e.g. rakudo isn't able to use a shared parrot ... yet).

Yes, but this is irrelevant, since those variables you reference are not currently intended to be used by an installed parrot,

Why should then the installed parrot config contain any references whatsoever to the build directory, which will in this scenario not exist?

It's not that it "should" contain such references. The question is why would anyone care if it contains such references. They are not intended to be used. They are useless. Irrelevant.

Whether parrot_config should be changed to make them useful and relevant is the subject of TT #649.

[pmichaud]

I agree with Andy that this isn't really a bug, so I'm marking this ticket as "wontfix" for now. Further discussion about what does or does not belong in parrot_config probably needs to be attached to TT #649.

Thanks,

Pm