[CMake] What does `cross-platform' mean?

[Mathias Fröhlich]

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