[GEM-dev] build error in trunk
Hans-Christoph Steiner
hans at at.or.at
Wed Apr 21 16:03:40 CEST 2010
On Apr 21, 2010, at 3:09 AM, IOhannes m zmoelnig wrote:
> On 2010-04-20 21:04, Hans-Christoph Steiner wrote:
>>>
>>> is there a reason why /sw is not in the PATH?
>>
>>
>>
>> Some build systems are not happy with the tools provided in /sw, so
>> its
>> good to make them optional. You can add /sw to the PATH within the
>> configure.in, then people will inherit that setting when building on
>> their own machine. I think its just a matter of adding this to the
>> top:
>>
>> PATH="/sw:${PATH}"
>>
>> .hc
>
>
> configure.in is probably a bad choice, as this file has to be
> processed
> by binaries found in /sw/bin, rather than has to call binaries in /
> sw/bin.
> i guess you meant autogen.sh
>
> anyhow, the problem with that is, that autogen.sh is a generic, and i
> don't feel like adding every single path anyone might happen to have
> on
> their machine :-)
>
> i guess it should be set more on a per-machine basis: after all the
> sysad of a certain host will always know best, which paths on the
> machine are relevant, whereas the choices of an upstream developer
> like
> me will always be bad.
>
> i will probably add /sw/bin to the path in the master build
> script/Makefile, if this is ok for you.
I think it should be targeted to where its needed. This sounds too
broad, tho I am not sure which Makefile you mean. Why not just do a
test against uname to set it in autogen.sh. Something like:
if [ `uname -s` -eq "Darwin" ]; then
PATH="/sw:${PATH}"
fi
.hc
----------------------------------------------------------------------------
If you are not part of the solution, you are part of the problem.
More information about the GEM-dev
mailing list