(0004879)
Brad King (manager)
2006-09-07 16:25

Thanks for creating this entry. Here are some comments:

The variable PWLIB_LIBRARIES should not be a cache entry. You should do

FIND_LIBRARY(PWLIB_LIBRARY ...)

and then

SET(PWLIB_LIBRARIES ${PWLIB_LIBRARY})

The idea is to separate the implementation of finding individual libraries (used by people running cmake) from the interface used by CMakeLists.txt code.

---------------------

You should not use NO_DEFAULT_PATH for the find commands unless there is a reason. Only a few big projects like Qt4 and KDE3 use this option. The option disables a whole bunch of nice automatic finding features. For example you don't need to list /usr/include or /usr/local/include because they are a default search location on UNIX platforms.

(0004880)
Brad King (manager)
2006-09-07 16:26

I'm assigning this bug to myself.

(0004881)
Frederic Heem (reporter)
2006-09-08 04:04

Regarding NO_DEFAULT_PATH, I've already explained why it has been added, cmake has to search for include files in $PWLIBDIR/include *FIRST*, then searching in the default directories, and not the opposite.
This is true for include files, library, binary. The variables $PWLIBDIR $OPALDIR or $ANYOTHERPROJECTDIR have the *PRIORITY* over system directory.
If not done this way, a project installed by default by the distribution and a development version of the same project cannot coexist. Both pwlib and opal are being developed, and opal need pwlib, opal must find header files in $PWLIB/include, not /usr/include/pwlib.

(0004882)
Frederic Heem (reporter)
2006-09-08 04:06

Actually, files shall be renamed FindOPAL.cmake and FindPWLIB.cmake, the reason was explained in the mailing list, it makes scripting easier.

(0004885)
Brad King (manager)
2006-09-08 13:20

Okay, you can use NO_DEFAULT_PATH to disable the default search, but you may want to then add references to variables like ${CMAKE_SYSTEM_INCLUDE_PATH} to restore the default search after your primary paths. See the documentation of FIND_PATH for the standard variables and ordering. Also please include in the comments the reason NO_DEFAULT_PATH is given.

(0004892)
Frederic Heem (reporter)
2006-09-12 03:25

What are your motivation to keep the existing path search order ? Every single project that defines an environment variable to set its directory will have to set NO_DEFAFUT_PATH and all the additional stuff required. The actual search order doesn't make sense.
Regarding the requirement:
"you may want to then add references to variables like ${CMAKE_SYSTEM_INCLUDE_PATH} to restore the default search after your primary paths."
Could you please add an example because this request is not trivial and I have no idea on how to achieve it.

(0004898)
Brad King (manager)
2006-09-13 12:55

You're right. There should probably be a way to add search paths that come before the standard path without requiring the call to the command to manually duplicate the standard search path.

The standard search path was designed to look for projects that don't require the user to set an environment variable for their location. The paths specified as arguments to the command are searched last because they are meant to be used as a last resort to locate the files. If a user sets the PATH environment variable before running cmake he/she would expect FIND_PROGRAM to locate the program where it first appears in that PATH rather than where the command happened to list. However, if the user sets a PWLIBDIR variable he/she would also expect that to be used before anything else. Therefore we should add the option to the FIND_* commands.

(0004899)
Brad King (manager)
2006-09-13 12:58

Actually, there is already a way to do this. From the documentation of FIND_FILE:

       The reason the paths listed in the call to the command are searched
       last is that most users of CMake would expect things to be found first
       in the locations specified by their environment. Projects may
       override this behavior by simply calling the command twice:

          FIND_FILE(<VAR> NAMES name PATHS paths NO_DEFAULT_PATH)
          FIND_FILE(<VAR> NAMES name)

       Once one of these calls succeeds the result variable will be set and
       stored in the cache so that neither call will search again.

(0004907)
Frederic Heem (reporter)
2006-09-14 04:08

"The paths specified as arguments to the command are searched last because they are meant to be used as a last resort to locate the files"
Actually, most of the library have an environment variable to set its root directory:
QTDIR, SDLDIR, JAVA_HOME, PWLIB, OPALDIR ....
These paths are the first resort to look for include, libraries etc ...
The key question is how many library specify path for the last resort and how many library specify path for the first resort.
Using FIND_PATH two times for almost all libraries is not natural.

(0004908)
Bill Hoffman (manager)
2006-09-14 08:45

With QT4 QTDIR is deprecated. But, maybe there should be a new keyword to avoid the double path. DEFAULT_PATH_LAST or something.

(0004909)
Frederic Heem (reporter)
2006-09-14 10:52

Let's add the optional DEFAULT_PATH_LAST, so NO_DEFAULT_PATH and double FIND_PATH becomes useless in the majority of scripts.

(0004910)
Frederic Heem (reporter)
2006-09-14 10:59

Do you mind review the modified version of the 2 scripts. They contains modifications you've requested

(0004911)
Frederic Heem (reporter)
2006-09-14 11:21

Is it possible to remove or update an attachment ?

(0004912)
Brad King (manager)
2006-09-14 11:29

I don't think this bug tracker allows it. I think the idea is to keep track of all information every produced.

Are you planning to put even newer versions or should I review the *.cmake_ versions?

(0004913)
Frederic Heem (reporter)
2006-09-14 11:41

These should be the last 2 ones

(0004920)
Brad King (manager)
2006-09-15 10:00

Thanks for the updates. Here are more comments:

In FindOPAL, the variable PWLIB_LIB_PATH_DESCRIPTION
should be named OPAL_LIB_PATH_DESCRIPTION.

The MESSAGE(FATAL) calls should be MESSAGE(FATAL_ERROR). Also these should not be fatal errors in all cases. See the bottom of FindBoost for the proper message logic.

(0006887)
Olivier (reporter)
2007-03-21 16:40

I still have a problem using this files because pkg-config cannot find pwlib nor opal on Debian...

There are no .pc files :( Do you know another method ?

(0006994)
Frederic Heem (reporter)
2007-03-29 10:29

The latest pwlib and opal from cvs are required.

(0030506)
Brad King (manager)
2012-08-13 10:36

Sending issues I'm not actively working on to the backlog to await someone with time for them.

If an issue you care about is sent to the backlog when you feel it should have been addressed in a different manner, please bring it up on the CMake mailing list for discussion. Sign up for the mailing list here, if you're not already on it:

http://www.cmake.org/mailman/listinfo/cmake [^]

It's easy to re-activate a bug here if you can find a CMake developer or contributor who has the bandwidth to take it on.

(0031070)
Brad King (manager)
2012-09-20 11:02

Module contributions now follow this page:

http://www.cmake.org/Wiki/CMake:Module_Maintainers [^]

(0032454)
Robert Maynard (manager)
2013-03-04 08:38

Closing resolved issues that have not been updated in more than 4 months.

Issue History
Date Modified	Username	Field	Change
2012-08-13 10:36	Brad King	Status	assigned => backlog
2012-08-13 10:36	Brad King	Note Added: 0030506
2012-09-20 11:02	Brad King	Note Added: 0031070
2012-09-20 11:02	Brad King	Assigned To	Brad King =>
2012-09-20 11:02	Brad King	Status	backlog => resolved
2012-09-20 11:02	Brad King	Resolution	open => won't fix
2013-03-04 08:38	Robert Maynard	Note Added: 0032454
2013-03-04 08:38	Robert Maynard	Status	resolved => closed

Notes
(0004879) Brad King (manager) 2006-09-07 16:25	Thanks for creating this entry. Here are some comments: The variable PWLIB_LIBRARIES should not be a cache entry. You should do FIND_LIBRARY(PWLIB_LIBRARY ...) and then SET(PWLIB_LIBRARIES ${PWLIB_LIBRARY}) The idea is to separate the implementation of finding individual libraries (used by people running cmake) from the interface used by CMakeLists.txt code. --------------------- You should not use NO_DEFAULT_PATH for the find commands unless there is a reason. Only a few big projects like Qt4 and KDE3 use this option. The option disables a whole bunch of nice automatic finding features. For example you don't need to list /usr/include or /usr/local/include because they are a default search location on UNIX platforms.

(0004880) Brad King (manager) 2006-09-07 16:26	I'm assigning this bug to myself.

(0004881) Frederic Heem (reporter) 2006-09-08 04:04	Regarding NO_DEFAULT_PATH, I've already explained why it has been added, cmake has to search for include files in $PWLIBDIR/include FIRST, then searching in the default directories, and not the opposite. This is true for include files, library, binary. The variables $PWLIBDIR $OPALDIR or $ANYOTHERPROJECTDIR have the PRIORITY over system directory. If not done this way, a project installed by default by the distribution and a development version of the same project cannot coexist. Both pwlib and opal are being developed, and opal need pwlib, opal must find header files in $PWLIB/include, not /usr/include/pwlib.

(0004882) Frederic Heem (reporter) 2006-09-08 04:06	Actually, files shall be renamed FindOPAL.cmake and FindPWLIB.cmake, the reason was explained in the mailing list, it makes scripting easier.

(0004885) Brad King (manager) 2006-09-08 13:20	Okay, you can use NO_DEFAULT_PATH to disable the default search, but you may want to then add references to variables like ${CMAKE_SYSTEM_INCLUDE_PATH} to restore the default search after your primary paths. See the documentation of FIND_PATH for the standard variables and ordering. Also please include in the comments the reason NO_DEFAULT_PATH is given.

(0004892) Frederic Heem (reporter) 2006-09-12 03:25	What are your motivation to keep the existing path search order ? Every single project that defines an environment variable to set its directory will have to set NO_DEFAFUT_PATH and all the additional stuff required. The actual search order doesn't make sense. Regarding the requirement: "you may want to then add references to variables like ${CMAKE_SYSTEM_INCLUDE_PATH} to restore the default search after your primary paths." Could you please add an example because this request is not trivial and I have no idea on how to achieve it.

(0004898) Brad King (manager) 2006-09-13 12:55	You're right. There should probably be a way to add search paths that come before the standard path without requiring the call to the command to manually duplicate the standard search path. The standard search path was designed to look for projects that don't require the user to set an environment variable for their location. The paths specified as arguments to the command are searched last because they are meant to be used as a last resort to locate the files. If a user sets the PATH environment variable before running cmake he/she would expect FIND_PROGRAM to locate the program where it first appears in that PATH rather than where the command happened to list. However, if the user sets a PWLIBDIR variable he/she would also expect that to be used before anything else. Therefore we should add the option to the FIND_* commands.

(0004899) Brad King (manager) 2006-09-13 12:58	Actually, there is already a way to do this. From the documentation of FIND_FILE: The reason the paths listed in the call to the command are searched last is that most users of CMake would expect things to be found first in the locations specified by their environment. Projects may override this behavior by simply calling the command twice: FIND_FILE(<VAR> NAMES name PATHS paths NO_DEFAULT_PATH) FIND_FILE(<VAR> NAMES name) Once one of these calls succeeds the result variable will be set and stored in the cache so that neither call will search again.

(0004907) Frederic Heem (reporter) 2006-09-14 04:08	"The paths specified as arguments to the command are searched last because they are meant to be used as a last resort to locate the files" Actually, most of the library have an environment variable to set its root directory: QTDIR, SDLDIR, JAVA_HOME, PWLIB, OPALDIR .... These paths are the first resort to look for include, libraries etc ... The key question is how many library specify path for the last resort and how many library specify path for the first resort. Using FIND_PATH two times for almost all libraries is not natural.

(0004908) Bill Hoffman (manager) 2006-09-14 08:45	With QT4 QTDIR is deprecated. But, maybe there should be a new keyword to avoid the double path. DEFAULT_PATH_LAST or something.

(0004909) Frederic Heem (reporter) 2006-09-14 10:52	Let's add the optional DEFAULT_PATH_LAST, so NO_DEFAULT_PATH and double FIND_PATH becomes useless in the majority of scripts.

(0004910) Frederic Heem (reporter) 2006-09-14 10:59	Do you mind review the modified version of the 2 scripts. They contains modifications you've requested

(0004911) Frederic Heem (reporter) 2006-09-14 11:21	Is it possible to remove or update an attachment ?

(0004912) Brad King (manager) 2006-09-14 11:29	I don't think this bug tracker allows it. I think the idea is to keep track of all information every produced. Are you planning to put even newer versions or should I review the *.cmake_ versions?

(0004913) Frederic Heem (reporter) 2006-09-14 11:41	These should be the last 2 ones

(0004920) Brad King (manager) 2006-09-15 10:00	Thanks for the updates. Here are more comments: In FindOPAL, the variable PWLIB_LIB_PATH_DESCRIPTION should be named OPAL_LIB_PATH_DESCRIPTION. The MESSAGE(FATAL) calls should be MESSAGE(FATAL_ERROR). Also these should not be fatal errors in all cases. See the bottom of FindBoost for the proper message logic.

(0006887) Olivier (reporter) 2007-03-21 16:40	I still have a problem using this files because pkg-config cannot find pwlib nor opal on Debian... There are no .pc files :( Do you know another method ?

(0006994) Frederic Heem (reporter) 2007-03-29 10:29	The latest pwlib and opal from cvs are required.

(0030506) Brad King (manager) 2012-08-13 10:36	Sending issues I'm not actively working on to the backlog to await someone with time for them. If an issue you care about is sent to the backlog when you feel it should have been addressed in a different manner, please bring it up on the CMake mailing list for discussion. Sign up for the mailing list here, if you're not already on it: http://www.cmake.org/mailman/listinfo/cmake [^] It's easy to re-activate a bug here if you can find a CMake developer or contributor who has the bandwidth to take it on.

(0031070) Brad King (manager) 2012-09-20 11:02	Module contributions now follow this page: http://www.cmake.org/Wiki/CMake:Module_Maintainers [^]

(0032454) Robert Maynard (manager) 2013-03-04 08:38	Closing resolved issues that have not been updated in more than 4 months.

Relationships