In other words, how to get a similar effect to that of . (dot) in bash or execfile in python in make.
Use the include directive:
include the-other-makefile
Reasonable ways in which you could have discovered this without asking it:
read POSIX 7 http://pubs.opengroup.org/onlinepubs/9699919799/utilities/make.html "Include Lines" (not present in 6 it seems)
by reading this tutorial from beginning to end before asking anything
by looking at the table of contents of this tutorial and knowing beforehand that you are probably looking for a so called directive (include is a directive)
guess that instead of source as in bash, it could be called include as in c, and then search for the include keyword in the GNU make manual
read the entire table of contents for the and deduce that include does what you need
Related
Is there any way to use macros or variables (à la bash) in a .gitignore script? The gitignore docs don't mention anything along those lines, but I figured I'd ask just in case there's some undocumented features and/or cool workarounds. A few people have asked about using environment variables in a .gitignore, but I want to know if there's any support whatsoever for macro-like or var-like anything.
use case
I have a repository which has been undergoing a refactoring of its directory structure/paths. Certain paths are used in multiple patterns in my .gitignore script, so it would be nice to be able to have something in there along the lines of:
# set a variable
UNSTABLE_PATH=foo/bar
# use the variable in some patterns
$UNSTABLE_PATH/test_data
$UNSTABLE_PATH/test_output
And yes, before you say it, I'm aware that clever use of glob and/or recursive glob could probably cover my use case. It would just be nice if there was some simple variable support as well. Though come to think of it I would also settle for a way to make the git mv command rewrite matching paths in the .gitignore.
Well, I'll just jump to the end of the semantics debate in the comments and leave it at this:
.gitignore is not a script, it's a list of patterns. As you would then expect, it has no support for variables.
If you really need this ability, I would take a cue from the likes of sass or less: Write your own file of "ignore rules with extended syntax" and write a script to boil that down into a proper .gitignore file.
But if you want my two cents, this looks like another case that would be resolved by moving some stuff outside your work tree, so that the work tree can just be a work tree.
Make(1) has built-in rules, such that for simple tasks you don't need a makefile at all. I can type make prog and if the current directory has a prog.c, make will do something useful.
I have a number of rules like this (e.g., how to make .pdf from .html) that apply in many projects. If I have a makefile in a directory, I can simply include my rules from a file. Is there a way to tell make to use this file always? Like a dot file that make would always include before doing anything else.
Make's rules are truly built-in, not read from a file. This has advantages (the entirety of make is one executable and you can copy it and install it anywhere and get identical behavior) and disadvantages (you can't modify the default rules without modifying the source code and recompiling--if you want to do that it's easy to do, though: see the default.c file in the sources).
You can specify an extra makefile (or makefiles) that should be parsed before the usual ones using an environment variable, though, so you can create a makefile with some extra rules, then (in your ~/.bashrc or whatever) set the MAKEFILES environment variable to the name of that file (or files) containing these extra rules (don't forget to export it).
Now every make invocation will load these rules as well.
You may discover, though, that this isn't quite what you'd hoped, because it could cause other makefiles to fail or act in bizarre ways (for example if you download open source packages and want to build them locally, etc.) If you do this just remember you did it, so in a few months if you run into issues you'll remember to try undoing it and see if it helps :-)
I have a #define ONB in a c file which (with several #ifndef...#endifs) changes many aspects of a programs behavior. Now I want to change the project makefile (or even better Makefile.am) so that if ONB is defined and some other options are set accordingly, it runs some special commands.
I searched the web but all i found was checking for environment variables... So is there a way to do this? Or I must change the c code to check for that in environment variables?(I prefer not changing the code because it is a really big project and i do not know everything about it)
Questions: My level is insufficient to ask in comments so I will have to ask here:
How and when is the define added to the target in the first place?
Do you essentially want a way to be able to post compile query the binaries to to determine if a particular define was used?
It would be helpful if you could give a concrete example, i.e. what are the special commands you want run, and what are the .c .h files involved?
Possible solution: Depending on what you need you could use LLVM tools to maybe generate and examine the AST of your code to see if a define is used. But this seems a little like over engineering.
Possible solution: You could also use #includes to pull in .c or header files and a conditional error be generated, or compile (to a .o), then if the compile fails you know it is defined or not. But this has it's own issues depending on how things are set-up in your make file.
Can Somebody explain me on short (just as idea) what the following fragment suggests?
- I'm new in C language so I don't understand the meaning of #...# sign:
#SET_MAKE#
VPATH = #srcdir#
pkgdatadir = $(datadir)/#PACKAGE#
pkgincludedir = $(includedir)/#PACKAGE#
pkglibdir = $(libdir)/#PACKAGE#
pkglibexecdir = $(libexecdir)/#PACKAGE#
or:
build_triplet = #build#
host_triplet = #host#
If is needed to put more code, let me know.
Thanks in advance.
The system of using names enclosed in # is used by autoconf to mark strings that should be replaced by the configure script.
These appear to be build-system variables of some sort, as the # symbol is not (I believe) used in C at all. Considering the names, this seems even more likely. The package and source directory will be inserted in the corresponding places.
Perhaps more interesting are the $(var)s, which are used often in Visual Studio project files (but not source, and a VS proj is a make file of sorts itself).
My guess is you have two make/build system variable types being used here. Whether they're from two system, I do not know. As Brian Roach pointed out in a comment, at least GNU autoconf is involved here.
What file did this come from, and what other text surrounds it? That may shed more light, if a well known name is used. It is possible this isn't a code file at all, and just a make file; or it could be a code file with build system variables in (for at-build replace).
This is not C at all, looks more like a makefile of some sort. Take a look at the filename where you found this, I doubt it ends in .c.
This question already has answers here:
Closed 12 years ago.
Possible Duplicates:
what is the difference between #include <filename> and #include “filename”
C/C++ include file order/best practices
In what order should the include statements in a header file and source file come in C++? #include <> followed by #include "" or the otherwise?
Also, should the header file of a source file precede all include statements in source file?
I prefer to include in this order:
Standard libraries first.
Then third-party libraries.
Lastly, headers that I have written myself.
A general rule of thumb is to include headers in an order so as to maximize the chance of detecting that one of your own headers fails to itself include all that it needs. I.e. include that first. But since it's impossible to do that for all headers that you include, this is just a kind of vague guideline that doesn't hurt and might do some good.
When you have many headers, try to be a bit more systematic.
Like, group them by what they achieve (like [windows.h] followed by some MS header that requires [windows.h]), and/or alphabetically.
In the end, just don't use too much time on this. :-)
Cheers & hth.,
There is no better or worse, they server different purposes. #ncude "" is supposed to be used for files in your project or direct dependencies that are not system wide installed. Where #include <> are for inludes that (eg under Linux) are located in your /usr/include or simialr folder, also called system libraries.
Just follow the project's existing conventions, if it has any for #include directives. If it doesn't, it doesn't really matter what you do as long as you're consistent.
This matters about as much as whether you put opening curly braces on their own line. I would suggest that you pick whichever one you like better, and be consistent.