Linux - GeneralThis Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
An easy way to convince yourself would be to try write a Makefile that will compile
the same program on multiple operating systems and accross many different architectures.
Also try to get a makefile to generate those .moc files used in Qt KDE compilations
across different operating systems and architectures.
Also your Makefile will have to take command line args to set various programs feature sets and default pathways so the user can cantroll how the program functions.
Some of the Unix guys don't use configure but they write a million Makefiles and you pick the one that works for you -- somehow that doesn't seem better.
Last edited by foo_bar_foo; 07-11-2004 at 11:14 AM.
I'm not really qualified to be discussing this but crosscompiling i think involves both compilng and linking against different than the native core libraries...
the whole configure thing is automated and is to help developers spend time writing programms rather than Makefiles -- the configure script itself is generated by autoconf based on a script generated by automake. configure can even be setup to generate the spec files for package managers.
I mean yea the Makefile is all just compiler commands ultimately you just have to get them into the Makefile somehow along with the other stuff your package needs to compile..
People for instance build Linux with different directory structures so you sometimes have to ask where things are and many libraries keep track of where their header files are installed in case configure asks..
If there are some platform specific defines (MACROS) you need to use as a workaround for something they are generated by config in config.h that becomes a part of the programs header files.
Autoheader takes as input the files acconfig.h and generates the config.h.in template by parsing configure.in.
then config turns config.h.in into config.h.
configure now rather than just checking for the needed symbols presence in the libs header files will actually go and check for the needed symbol in the library itself. and can check for functions within the std c lib.
to make sure they are present so your newly compiled programm will actually run.
libtool can keep track of the extent of backward compatability in a certain library.
and of course like i said earlier configure allows you to install things in unorthodox places with different config file locations or using external rather than internal libraries of even do a total static linkage disable some functionality you don't like or whatever.
for a look at a non-configure alternative check out the cdrtools package
i have looked at that Makefile system for hours and have no idea how it works
Personally, I would rather have configure tell me I need libfoo >= 2.42.493, rather than start a make, leave, come back 5 hours later, and find out it failed after 5 minutes with some obscure error message which may or may not be because I need to upgrade libfoo.