On 2008-04-14 21:55-0400 Bill Hoffman wrote:
Alan W. Irwin wrote:
On some platforms, X11_LIBRARIES derived by FindX11.cmake is going to be a
mixture of full pathnames for libraries and a series of -l flags which is
not a recommended form for CMake 2.6.x. To see this, look at the
FindX11.cmake logic for CMake-2.6.0-RC-8.
OK, -l flags are fine with cmake 2.6.x, let me say that again, -l is OK with
2.6. It MAY cause a link error. If you set CMP0003 to NEW, it you can find
out. If CMP0003 is set to NEW and you stuff links, that is not a hack, that
is the right way to do it.
X11_LIBRARIES is used for a variety of linking tasks for PLplot (some for
PLplot libraries, some for PLplot device driver plugins) with more being
added from time to time (such as our cairo device driver that was added a
year ago). Also, the current problem is a corner case that doesn't even
occur on our most tested platform (Linux) since X11_X_EXTRA_LIBS is empty
there. Thus, "MAY cause a link error" produces enough current platform
uncertainty and future overall uncertainty that I prefer to avoid -l flags
if at all possible in X11_LIBRARIES.
You should never use -L directly (in TARGET_LINK_LIBRARIES) .....
link_directories should be used.
Our use case is we have a large number of libraries and plugins, but only
four of those (IIRC) use X11_LIBRARIES. I prefer to use -L directly in
TARGET_LINK_LIBRARIES rather than use the LINK_DIRECTORIES alternative since
the latter would would add an unnecessary (and possibly inefficient)
directory search for the link steps for most of our libraries/plugins. Of
course, this entire issue is moot if -l flags never appear in X11_LIBRARIES
for any platform because then I could drop the -L flag altogether.
warnings without compromising the need of some who require a non-standard
install location for X.
I guess I would suggest that you should experiment with a new version of
FindX11 in plplot. If you find it works well, we can look at it for
inclusion in 2.6.1.
I have too much on my plate, and I also don't know enough about X on the
various Unix platforms to really do a good job here. For example, I suspect
all the X11_X_EXTRA_LIBS (the source of the -l trouble) is simply copied
from some ancient autotools script and may not be relevant any more, but I
don't know for sure. On Linux X11_X_EXTRA_LIBS is empty. Does anybody know
if it is still actually useful for any X? If it is no longer relevant then
you could guarantee fullpath for X11_LIBRARIES by replacing
SET(X11_LIBRARIES ${X11_X_PRE_LIBS} ${X11_LIBRARIES} ${X11_X_EXTRA_LIBS})
by
SET(X11_LIBRARIES ${X11_X_PRE_LIBS} ${X11_LIBRARIES})
In the long run full paths would be a good idea for
FindX11, but not a requirement right now.
Fair enough. However, if there is a simple fix that some X cross-platform
expert could recommend (such as eliminating X11_X_EXTRA_LIBS from the
X11_LIBRARIES definition as above), then the long run might be short indeed.
Alan
__________________________
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________
Linux-powered Science
__________________________
_______________________________________________
CMake mailing list
[email protected]
http://www.cmake.org/mailman/listinfo/cmake
