[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