Hello. I recently have been trying to use the autotools in a already existing program that I used an IDE before. I started to follow this tutorial: autoconf automake tutorial
And it was going well until came the hour of I assuming the end-user job. ./configure runned ok, but when I typed "make" in the top level directory, I received this:
make
make all-recursive
make[1]: Entering directory `/media/34GB/demos/asmfrt'
Making all in src
make[2]: Entering directory `/media/34GB/demos/asmfrt/src'
Makefile:510: *** missing separator. Stop.
make[2]: Leaving directory `/media/34GB/demos/asmfrt/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/media/34GB/demos/asmfrt'
make: *** [all] Error 2
I opened the makefile in the src dir, went to line 510 and I saw this:
.
Yes, there is a single '.' in the line
The previous line is a blank line and the succeeding line is another '.'
So, what might be going on and how to fix it. Thanks for your time
Quite likely autoconf, automake, and libtool have broken backwards compatibility with themselves again. They do this every few years without fail. I've had similar experiences with IDE's depending upon them. They do not last.
If you're lucky, you can upgrade your package with autoreconf followed by libtoolize --force, but this is a long shot. autoconf and automake have been been outpacing moore's law in complexity and brokenness for over 20 years.
It may be far better to take 5 minutes to write a simple makefile yourself than spend 3 months fighting this monstrous, obsolete code generator-generator-generator.
It works, but it's not using the compiler flags to speedup the code. I realisz that the problem is that the flags are in the wrong place, they should be before the .o files are created. I guess I shall put them in the CFLAGS? I read somewhere that since the CFLAGS are made to be adjusted by the end-user, it's a bad practice to set them in the Makefile. If that is the case, where should I put the compiler flags?
Besides that, I do not comprehend the purpose of "-I". The tutorial says
. But doesn't always gcc looks in the current directory for .h files? As far as I know, it's the double "" around a .h file that makes gcc look in the current directory for the file, if it was <>, it would look for them in the global directories like /usr/include.
Not gcc but actually cpp. It is convenient to think of the compiler as one huge, monolithic program but this is not the case. And the preprocessor - cpp - is the first one in the chain that devours source code and digests it to executable code.
You can actually bring cpp to show you the default location(s) it would look at for header files by issuing cpp -v . The relevant part of the output would look similar to (the redirection is necessary, otherwise it waits for input):
Apart from"see above", this is "more or less correct but not quite". ;-)) In fact the preprocessor doesn't look in the current directory but the one where the source file is located. If you compile a source file in the current directory (which is mostly the case) this makes no difference but if you do:
and in the source there is the line #include "myprogram.h" then cpp would look in /some/where/ for myprogram.h and not your current directory /my/current/directory . I suppose this makes a lot more sense than if it would be the other way round.
Regarding your question about the location of CFLAGS: be aware that the construction of the commandline is done simply by text replacement. Where the name of a variable (like $(CFLAGS) ) stands it is replaced by the content of that variable. The called program will only "see" the result of these replacements, so ask yourself: would the resulting compiler call be syntactically correct or not?
