I need a way to generate part of the resulting makefile beyond what Automake can provide. That is, the rules cannot be generated from standard Automake. However, with a simple bit of substitution it would be easy to convert some basic parameters into the makefile chunk. I see that autoconf uses M4, but apparently the automake part doesn't (in Makefile.am). So is there any way to use some kind of macro facility in the Makefile.am files?
Essentially I just want a macro facility. If there is no automake way I'll resort to using GNU makefile templates.
There is no general purpose macro facility built into automake.
Related
The GNU Makefile has a documentation page which lists standard implicit variables for various compilation contexts, such as CC, CFLAGS, etc. They are well defined, and pretty safe to employ (I use them all the time).
Looking though extended documentation, beyond the GNU website, I regularly see other variables which are not listed on the GNU documentation, such as COMPILER.c, LINK.o, etc.
Such variables are present in multiple recipes when looking over Github or Internet, and frequently from authors which seem to have a pretty good understanding regarding how make works.
The question is:
How reliable is it to use such variables?
They are not documented on the GNU make documentation website, but they seem stable enough that several authors have decided to rely on them. Is it a sane thing to do?
I'd say that they are documented and are pretty safe to use with GNU make (they are not in POSIX make).
However, the recipes in built-in implicit rules actually use variables such as COMPILE.c, LINK.p, and PREPROCESS.S, whose values contain the recipes listed above.
make follows the convention that the rule to compile a .x source file uses the variable COMPILE.x. Similarly, the rule to produce an executable from a .x file uses LINK.x; and the rule to preprocess a .x file uses PREPROCESS.x.
I would like to know the Uses of static pattern rules against normal rules in make. I an new to make and gone through some tutorials. I want to know when do we use this static pattern rules ? Could you please explain in brief ?
Thanks in Advance.
Your question is mostly a matter of opinion. Notice that there are several build automation tools (not only GNU make), e.g. also ninja, scons, omake, etc...
When you code in C (or in C++....) some project, you could have some C (or C++) files which are generated from something else (e.g. by lemon or by your own utility...). For such cases (pedantically you could call them metaprogramming), pattern rules could be useful (in particular if you have several such cases in a project). In other cases you generate other files (than object files) from C source (e.g. generating documentation with doxygen), and then pattern rules are also very useful.
An example of a large C++ project with many C++ code generators is the GCC compiler. And back when (in 2009) GCC was coded in C, it already had a dozen of specialized code generator programs emitting some C code. For these cases, pattern rules could be convenient.
Of course, pattern rules are a luxury. You could in principle generate your Makefile and have it contain a simple rule for each individual file. (in GCC, the Makefile-s are generated by autoconf and automake based things...)
If you observe and study the source code of most large free software projects, you'll find out that most of them do have generators for C (or C++) files. So generating C code is a usual practice (the original Unix from late 1970s did that already). Today, some software projects have most or even all (e.g. CAIA) of their C code generated.
Cppcheck is the tool which analyses our CPP code. I want to create custom rule for Cppcheck to check whether all functions have comments or not. For that I need a PCRE (Pearl regex) pattern. Or any other predefined rules to address this scenarios.
There are some predefined rules available # installerlocation\cfg, what is the purpose of it? whether we can write rules using it instead of tools?
I am a cppcheck author. Yes, you can write rules using PCRE expressions. But as far as I know you can't see if there are comments from a rule. As far as I know, all comments and indentation are removed before any rules are executed.
I'm wondering where are gcc macros like builtin_expect , __attribute ((warn_unused_result)) etc. stored ? I needed to create a tag file with ctags , for things like those above.
Thanks !
_builtin_expect is a GCC builtin, this means that the compiler has some special code to handle it. It it nowhere really defined; if you care about its implementation, look inside the file gcc/builtins.c (& builtins.def) of the GCC 4.6 (or future 4.7) compiler source code.
Likewise, __attribute__-s are handled by the compiler.
The GCC documentation lists the set of builtins & attributes understood by GCC. Plugins (or MELT extensions) for GCC can augment it.
Some of these, like all __attribute__() are special keywords handled directly by the compiler.
I have some files that have a particular syntax that is similar to ada (not identical though), however I would like to verify the syntax before going and running them. There isn't a compiler for these files, so I can't check them before using them. I tried to use the following:
gcc -c -gnats <file>
However this says compilation unit expected. I've tried a few variations on this, but to no avail.
I just want to make sure the file is syntactically correct before using it, but I'm not sure how to do it, and I really don't want to write an entire syntax checker just for this.
Is there some way to include an additional unsupported language to gcc without going through a recompile? Also is this simply a file that details to gcc what the syntax constructs are, or what would be entailed? I don't need a full compile, only a syntax check.
Alternately, are there any syntax checkers I can use that I can update an ada syntax check with the small number of changes required for this language?
I've listed Ada as a tag, since the syntax is nearly identical, and finding something that will do ada syntax checking without compiling will be a 90% solution for me.
You could try running the files through gnatchop first. The GCC Ada compiler is rather unique in that it expects filenames to match up with the main unit names inside the file. That may be what your error message is trying to say.
gnatchop will go through any files you give it and write out Ada source files with the appropriate names to make gcc happy (even splitting files into multiple files if needed).
Another option you might be interested in is OpenToken. It is a parser construction toolkit, written in Ada, that allows you to build your own parsers fairly easily. It comes with a syntax recognizer for Ada, so you may just be able to tweak that a bit for your needs.