View Issue Details [ Jump to Notes ] | [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0000264 | CMake | public | 2003-10-09 11:25 | 2004-04-16 07:55 | |||||
Reporter | Bill Hoffman | ||||||||
Assigned To | |||||||||
Priority | low | Severity | minor | Reproducibility | always | ||||
Status | closed | Resolution | fixed | ||||||
Platform | OS | OS Version | |||||||
Product Version | |||||||||
Target Version | Fixed in Version | ||||||||
Summary | 0000264: FIND_* needs a more general way of handling system path | ||||||||
Description | 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. Perhaps all the FIND_* stuff should be generalized. | ||||||||
Tags | No tags attached. | ||||||||
Attached Files | |||||||||
Relationships | |
Relationships |
Notes | |
There are no notes attached to this issue. |
Notes |
Issue History | |||
Date Modified | Username | Field | Change |
Issue History |
Copyright © 2000 - 2018 MantisBT Team |