Software that doesn't use DESTROOT and funny tarball directories
Watson Ladd
watsonbladd at gmail.com
Tue Jul 19 07:32:46 PDT 2016
On Tue, Jul 19, 2016 at 5:19 AM, Ryan Schmidt <ryandesign at macports.org> wrote:
> On Jul 19, 2016, at 7:13 AM, Ryan Schmidt wrote:
>
>> On Jul 17, 2016, at 12:31 AM, Watson Ladd wrote:
>>
>>> The problem is that
>>> they want you to run configure with an argument indicating the install
>>> prefix, then don't seem to support DESTROOT. I've gone to upstream to
>>> report this, but I understand there is black magic we could use
>>> instead.
>>
>> Looking in https://github.com/cisco/ChezScheme/blob/master/makefiles/Mf-install.in, it looks like this project's Makefile supports a variable TempRoot which is equivalent to what other projects call DESTROOT. So you can set:
>>
>> destroot.destdir TempRoot=${destroot}
>
> Sorry, I see I'm late to the party, and Josh already mentioned that this project's configure script has a flag for specifying temproot.
>
> This is one of the problems with projects that roll their own nonstandard configure scripts and Makefiles -- they don't work the way anybody unfamiliar with that project expects. Developers would do well to adopt standard configure script and Makefiles made with autotools since everyone already knows how they work and using standardized well-tested tools like autotools avoids problems project developers may not even know exist.
>
A bit later then that: I've figured it out, made a portfile, and am
now working with upstream on getting CC honored. See
https://github.com/cisco/ChezScheme/issues/82 for the upstream bug,
and feel free to add anything if I've missed it.
Once I submit the build system changes, I don't know what will happen
in terms of them tagging a new release.
Sincerely,
Watson
More information about the macports-dev
mailing list