[Cmake] ar+ranlib detection

[William A. Hoffman]

Yes, that is the problem.  I think I may change the order that things are
looked for in CMake.  I will change all of the FIND_* things to look
in PATH before any additional options given to the command.
This will require a c++ level change to cmake.

I have checked in the chage in cvs.  It is in Source/kwsys/SystemTools.cxx.
I think we can put this patch in the next release.

-Bill




At 03:22 PM 10/9/2003, Doug Henry wrote:
>It would appear the modules have similar problems.  If I install libjpeg
>in /server/tools and use FindJPEG I get jpeg in /usr/include and
>/usr/lib.  I assume if I want to find anything in my toolchain I will
>have to call the FIND_xxx functions directly.
>
>On Thu, 2003-10-09 at 11:26, William A. Hoffman wrote:
>> This does look like a problem.   However, the problem is
>> a bit complicated.
>> 
>> Basically, the FIND_PROGRAM command looks like this:
>> 
>> FIND_PROGRAM(CMAKE_AR NAMES ar PATHS /bin /usr/bin /usr/local/bin)
>> FIND_PROGRAM(CMAKE_RANLIB NAMES ranlib PATHS /bin /usr/bin /usr/local/bin)
>> 
>> And it works by looking in the paths specified to the command first,
>> then in the environment variable $PATH.   So, you get the bad behavior
>> where cmake made find something not in your path.   
>> 
>> One option to fix this would be to change the order, so that FIND_PROGRAM
>> looks in the PATH first then in the other paths passed into the command.
>> However, this may produce different results than cmake has in the past.
>> A better option would be to specifically ask for the system path in the command,
>> so cmake list writers could decide where to put the path.
>> 
>> Something like this:
>> 
>> FIND_PROGRARM(CMAKE_AR_NAMES ar PATHS SYSTEMPATH /bin /usr/bin /usr/local/bin)
>> 
>> You could not use $ENV(PATH) because path can be ; or : separated depending on the OS.
>> 
>> I will enter this as a bug.
>> 
>> For now, if you want a quick fix, you can change this file:
>> 
>> CMake/Modules/CMakeDetermineCCompiler.cmake
>> 
>> And remove the extra paths for CMAKE_AR and CMAKE_RANLIB.   For those programs
>> it makes sense that cmake should not have extra paths anyway.  So, I will check
>> in the fix to cvs cmake, and it should be in the next 1.8.2 release.
>> Thanks for the report.
>> 
>> -Bill
>> 
>> 
>> 
>> At 09:37 AM 10/9/2003, Doug Henry wrote:
>> >I have a development toolchain built independently of my linux distro. 
>> >For example, binutils and gcc are in a dir called /server/tools/bin. 
>> >This path is first in my bash PATH.  When I run cmake my compilers get
>> >detected according to my path, but the binutils (ar, ranlib, etc) are
>> >always detected in /usr/bin.  Shouldn't they also be detected from the
>> >path search order?  Is there a way I can fix this without having to
>> >manually change it through ccmake?
>> >
>> >Thanks
>> >
>> >
>> >_______________________________________________
>> >Cmake mailing list
>> >Cmake at www . cmake . org
>> >http://www . cmake . org/mailman/listinfo/cmake
>> 
>> 
>> _______________________________________________
>> Cmake mailing list
>> Cmake at www . cmake . org
>> http://www . cmake . org/mailman/listinfo/cmake