> But what is the alternative if you want to build shared libraries
> portably?
I don't know about Scons, but you can use CMake, and it will just work:
add_library(foo SHARED foo.c bar.c)
This will give you depending what you need:
-UNIX Makefiles (not quite sure if it requires GNU make, I don't think
so)
-MS nmake makefiles
-Borland Makefiles
-Watcom Makefiles
-cygwin Makefiles
-XCode projects
-Visual Studio >= 6 projects.
I wondered for years why suddenly the comopiler can't be called directly
anymore, to find out that it's just libtool and you can use the compiler
very well directly (which removes one layer of indirection -> makes it
easier to understand).
Alex
Posted Feb 7, 2008 17:11 UTC (Thu) by stevenj (guest, #421)
[Link]
UNIX Makefiles (not quite sure if it requires GNU make, I don't think
so)
You are sorely mistaken if you think that there is one way to build shared libraries that works on all flavors of Unix. If you only care about Windows, GNU/Linux and similar systems with gcc, and MacOS X, then yes, generating three makefiles will work, but that's not solving anything like the whole problem.
automake vs. GNU make
Posted Feb 7, 2008 23:17 UTC (Thu) by aleXXX (subscriber, #2742)
[Link]
CMake knows how to build shared libs on all supported platforms (which
support shared libs) with all supported toolchains (GNU, IBM, Sun,
Borland, MS, Portland, Intel, HP and more). For several
platforms/toolchains this is tested every night (unfortunately there
aren't nightly tests for all supported combinations).
http://www.cmake.org/Testing/Dashboard/20080206-0100-Nigh...
Alex
automake vs. GNU make
Posted Feb 8, 2008 5:50 UTC (Fri) by lovelace (guest, #278)
[Link]
The makefiles CMake generates are not portable and can only be used on the system that they're generated on. If you move to a different system, you use CMake to generate makefiles for that system. That's how they can reliably create shared libraries on multiple systems using makefiles.