4 ms·
> You just compile with -lpng. If libpng is available, it will work, otherwise it will fail with a clear error message. What else do you need? well, no you don
by jcelerier 8y ago
> You just compile with -lpng. If libpng is available, it will work, otherwise it will fail with a clear error message. What else do you need?
well, no you don't "just compile", because one of the most used compilers out there does not support "-l". Also because you may have multiple libpng versions on your machine - debug, with special testing flags, in your ~/work/libpng_build, etc.
Also, you may have libpng.so but not the headers. You may be compiling on Nix or GoboLinux or whatever system which does not respect the FHS. It won't work as is on OS X because you have to add -L/usr/local/lib. Users won't know what to do when they see whatever missing include error the compiler spits out.
> doing that in cmake would be a nightmare, wouldn't it?
.. it would be mostly the same than your example ? just tested and this works fine (normal practice with cmake is to build outside of src which helps):
for i in gcc clang; do
for m in "-DCMAKE_BUILD_TYPE=Debug" "-DCMAKE_BUILD_TYPE=Release"; do #not using -g because that's something compiler-specific
rm -rf ** ; CC=$i cmake ../ $m ; cmake --build .
done
done
- enriquto 8y agoThanks for your answer, I see that cmake is not as cumbersome as I thought. > Also, you may have libpng.so but not the headers. Then how on earth are you supposed to compile it? You write the definitions verbatim on your code? > It won't work as is on OS X because you have to add -L/usr/local/lib. For that case it is better to not mess with compiler options and set up the compiling environment so that -lpng works, e.g. by setting LIBRARY_PATH=/usr/local/lib, and similarly for C_INCLUDE_PATH. These variables are recognized by all unix linkers and compilers that I care about. Of course, this attitude may not be appropriate for everyone. Yet, I am in the happy position to be able to say say "this program requires gcc, clang, tcc or icc to be compiled, otherwise, please edit the makefile to suit your needs". Are there really other C compilers around? (notice that visual studio is not a C compiler, and cannot compile modern C code, so it does not enter into the discussion if you are a C programmer).
- jcelerier 8y ago> Then how on earth are you supposed to compile it? You write the definitions verbatim on your code? what I mean is that an user might download your source archive, run `make`, and have hard-to-understand failures because of this.
- pjmlp 8y agoYes, quite a few, mainframes, embedded OSes, bare metal deployments for SoC, surviving commercial UNIXes.
- tom_ 8y agoSpare your fingers ;) - you'll never convince anybody of the value of cmake by telling them about it. You just have to put them in a situation where they're looking after a program that has to build on multiple desktop platforms, and they'll figure it out eventually... (The combination I've always had to deal with is Linux, OS X and Windows/VC++ - but any combination that includes both Windows/VC++ and a POSIX-type OS is probably enough to make it worthwhile. The POSIX/non-POSIX differences are rather annoying to deal with otherwise, and that quite apart from how most Windows programmers will quite reasonably want to use a Visual Studio project rather than a Makefile.) 506c
- enriquto 8y agoI hope this day never arrives for me... In any case, if I ever had to compile something for windows I would rather install cygwin and a posix toolchain than cmake and visual studio.
- deleted 8y ago[deleted]
- AHTERIX5000 8y agoYeah, CMake and autotools solve different problems than make. I'm definitely not a fan of either one but if I need to really distribute and compile something on more than one OS there isn't much of a choice. The posted makefile example fails right away on multiple platforms since headers are often in somewhere else than in /usr/include directly, for example in Debian the right (atm) path would be /usr/include/libpng16 and Makefile does not handle that.
- enriquto 8y ago> The posted makefile example fails right away on multiple platforms since headers are often in somewhere else And that's the intended behavior. Finding system headers around your disk is not a problem that a build system must try to solve. This is the task of a distribution or a packaging system, which is a different problem as you say.