Good morning, On Monday 10 November 2008 16:46, Bill Hoffman wrote: > OK, so perhaps the FindFoo.cmake modules should always use a try-compile > to test the library that is found works with the current ABI. This > will likely slow things down quite a bit... This would require some > extra thought.... Sure, this is what most people tell about autotools. They are slow. That is for a huge amount because of exactly that reason, that they test what they need to test. And this usually includes starting up a compiler, compiling a small testprogram pulling half of the includes of the installed system, linking, executing, testing return value ....
> Perhaps the abi can be determined without a > try-compile, but I am not sure that would work on all platforms. That would be indeed the way cmake handles these things. But this requires plenty of special case handling. Think of linker scripts on gnu binutils based systems. This is a simple text file doing complicated things with some elf binaries. look into /usr/lib/libc.so of a recently new libc (here suse 10) - understand the documentation from 'info ld' regarding 'Scripts', read that linker script file from cmake and reimplement the semantics of the linker scripts with cmake, just to see if you could later link with that file. Ok, I forgt, you also need to track further development of gnu ld's scripts to make cmake work in the future - may be decide which version of ld is installd to simulate different versions behaviour of ld. Ok, done so far, now we have just handled gnu ld based systems. That is mostly 'linux systems'. To be real 'cross platform' now start thinking about all the other unix flavours with all those merits and they have. There is a, if I remember right, 700 page red book describing linking on AIX. They have plenty of good and usefull and at some places strange ideas at IBM, but you need to know and understand all those ideas, if you want to make cmake decide if you could link with a library. All the nice stuff HP has hiden in the shared library handling. With all the problems introduces with files explicitly linked with full paths. Just to name some things you need to know and learn and maintain if you want to make cmake aware of that problem. And all that stuff, just to know if you can link with such a library? Any again, it does not help the final build if cmake *thinks* the linker can link with such a library. For the build, the linker must be able to link. ... Test what you need. Also think of debugging transparency for the user of cmake. This is a problem with all of the configuration systems I know. You have a black box and you do not know what happens inside. Suppose you have installed a system with library 'a' installed and you have downloaded project 'b' based on cmake. But that project claims not to find liba. Why? liba is there, I can link with it, I can run programs with it, it works pretty well, but cmake's black box system has decided not to find it... ??? Being able to link a program and run it with that library is IMO a good and *simple* thing a user can easily test. And if this does not work, a user can isolate the test case and run that test compile/link with more verbose flags and see why it breaks or not. This is much harder for a user if this is all done somewhere in the c++ code in some subtile different way than the linker does it later at compile time ... ... my 2 cents for that problem. ... and yes, at some point in the future somebody will start beating cmake because of being so slow. This guy will then start a new project for a build system. And people need again tell this guy that the other systems in this area are slow for a good reason. :) Greetings and thanks Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Florian Geyer, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Prof. Dr. Hanns Ruder Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 _______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
