Currently in my Makefile I have:
prefix ?= /usr/local
So that I can override prefix value when calling make, like in the following:
make prefix="/new_path"
My question is: does a convention exist for naming this variable inside a Makefile, especially do I have to call it prefix or PREFIX?
This matter since lower or upper case matters in this situation!
Note that I do not use autotools, just a "simple" Makefile
The variables for installation directories section of the GNU make manual discusses prefix.
I believe the autotools use a similarly-cased prefix variable/configure flag.
Compare to DESTDIR however.
Related
I have some issues with the behavior of the wildcard function of GNU Make with respect to terminating slashes in the pattern and the output.
Consider the following simple directory structure:
dir
|
+-- file
|
+-- subdir
On Linux,
$(wildcard dir/*/) # (1)
evaluates with GNU Make 4.1 to
dir/subdir/ dir/file
but with GNU Make 4.3 to
dir/subdir/
One could argue whether including the regular file filein the former case is a bug or a feature (names of directories but not those of regular files are terminated with a slash). However, both versions of GNU Make evaluate
$(wildcard $(addsuffix /,$(wildcard dir/*))) # (2)
to
dir/file dir/subdir/
(subject to sorting). In particular, $(wildcard dir/file/) evaluates to dir/file. This is more in the spirit of the above GNU Make 4.1 feature but seems to be somewhat inconsistent with respect to GNU Make 4.3.
What can I assume from the wildcard function regarding a terminating slash in the pattern?
I would like to determine the content of a directory such that the names of subdirectories are terminated by a slash while the names of regular files are not. In GNU Make 4.1 I used approach 1 which broke my build with GNU Make 4.3. In both cases I could use approach 2. But is this feasible or do I rely on undefined behavior here? If so, what would be the correct (and efficient) way to do what I want?
The problem is not simple. The short answer is that the behavior of GNU make 4.3 is correct for the expansion of dir/*/ and the behavior of earlier versions of make that don't agree with that, are wrong.
As for the behavior of dir/file/ that seems to me to be wrong in all versions of GNU make; that is, it should return the empty string.
However, GNU make doesn't actually implement its own file globbing, at least not on systems that provide the GNU libc C runtime library, which is most Linux systems. It simply calls the system-provided glob(3) function. I wrote a small test program that simply calls GNU libc's glob(3) function directly and it gives the same behavior as GNU make 4.3:
dir/*/ -> dir/subdir/
dir/file/ -> dir/file/
In my opinion this is a bug in GNU libc's glob(3) but perhaps I'm missing some subtlety here.
In any event, if what you really want is just directories then the best/safest/works everywhere solution is to use this:
$(wildcard dir/*/.)
then you don't have to worry about magical behaviors related to trailing slashes.
The function wildcard-rec in the GNUmake table toolkit does exactly what you want. It distinguishes between files and directories via a obvious feature: if the given glob ends in / then you want directories, if the / is absent you want files.
include gmtt.mk
$(info $(call wildcard-rec,**.c)) # all C source files in the tree
$(info $(call wildcard-rec,**.c **.h)) # a C source and header files
$(info $(call wildcard-rec,drivers/**.c)) # only sources for the `drivers` tree
$(info $(call wildcard-rec,drivers/**/test/)) # all test subdirectories in the `drivers` tree
$(info $(call wildcard-rec,drivers/**/test/*.cfg)) # config files in all test subdirectories in the `drivers` tree
I'm writing a static pattern rule to generate a list of dependencies for targets matching a pattern. The dependencies are generated through a shell command (the file content gives information about the dependencies). Here's an example of the explicit rule:
f1.o: $(shell gendep src/f1/f1.source)
... (some compilation command here) ...
While this works, I do not want to rewrite it for each new target since I'm maintaining the same file structure. My attempt at static pattern rule was like so:
%.o: $(shell gendep src/%/%.source)
...
I'm having trouble passing the stem (matched pattern for %) to the shell command. The shell command interprets it literally and operates on src/%/%.source, which of course doesn't exist.
I suspect there is way of passing the stem to the shell command but I don't seem to find it. Any experts here might be able to help me? Sorry if this is a newbie question (I'm indeed one).
What you're trying to do is difficult, because ordinarily Make will expand the $(shell ...) directive before running any rule, or even deciding which rules must be run. We can retard that by means of Secondary Expansion, a slightly advanced Make trick:
.SECONDEXPANSION:
%.o: $$(shell gendep src/$$*/$$*.source)
...
There are also other methods for automatic dependency generation.
What is the reason for having both a CCFLAGS and a SHCCFLAGS variable in the SCons environment?
I am trying to modify a large program build that I did not write myself. When I add the command:
env.Append(CCFLAGS=["-I%s" % amber_dir, "-DAMBER"])
the compiler runs without the flags I added. But when I do
env.Append(SHCCFLAGS=["-I%s" % amber_dir, "-DAMBER"])
the compiler adds my flags as wanted. Somewhere in SCons' innards, CCFLAGS are is not passed to SHCCFLAGS. But why have a CCFLAGS and a SHCCFLAGS to begin with?
This is taken from the SCons User's Guide: SCons Construction Variable
CCFLAGS
General options that are passed to the C and C++ compilers.
CPPFLAGS
User-specified C preprocessor options. These will be included in any
command that uses the C preprocessor, including not just compilation
of C and C++ source files via the $CCCOM, $SHCCCOM, $CXXCOM and
$SHCXXCOM command lines, but also the $FORTRANPPCOM, $SHFORTRANPPCOM,
$F77PPCOM and $SHF77PPCOM command lines used to compile a Fortran
source file, and the $ASPPCOM command line used to assemble an
assembly language source file, after first running each file through
the C preprocessor. Note that this variable does not contain -I (or
similar) include search path options that scons generates
automatically from $CPPPATH. See $_CPPINCFLAGS, below, for the
variable that expands to those options.
SHCCFLAGS
Options that are passed to the C and C++ compilers to generate
shared-library objects.
SHCCCOM
The command line used to compile a C source file to a shared-library
object file. Any options specified in the $SHCFLAGS, $SHCCFLAGS and
$CPPFLAGS construction variables are included on this command line.
The most interesting of the 4 mentioned above are the SHCCCOM and CPPFLAGS variables. Try your test again setting CPPFLAGS instead of CCFLAGS.
A general comment about the flags you are setting: with SCons, its generally better to set include paths with the CPPPATH variable, and to set defines with the CPPDEFINES. When using these variable, you dont need to include the -I, nor the -D flags, SCons will add it for you in a platform-independent manner. Here's an example:
env.Append(CPPPATH=amber_dir)
env.Append(CPPDEFINES='AMBER')
You'll need to test this to see if the SharedObject() and/or SharedLibrary() builders use those, I would imagine they would.
Answers to questions in comment below:
SHCCCOM is just used to see what the command line looks like, sometimes you may need to use it without using the SCons builders directly. SHCCFLAGS is a super-set of CPPFLAGS and others and should be used when you have flags that you only want to pass to SharedLibrary() or SharedObject(). CPPFLAGS applies to both static and shared compilations.
As you know the getch() and getche() functions don't work with the cygwin, a linux oriented one.
But can I include the conio.h header file of borland c and call the functions getch in my makefiles?
Will it work and can anyone tell me how to include the header files from different directories in cywgin.
I have a header file strcal.h in directory c:/makk/string/.
How do I include that header file in my makefile?
gcc -I/string small.c
It is not working and my current directory is makk.
In stdio.h, there is a getchar() function which is what you need. You can't just bring across the Borland header file since that just declares the function, it doesn't define it. Standard C has no need for getch().
To include header files in different areas, you use the -I directives of gcc to set up search paths.
So, if you have a /xyz/myheader.h file, you can do something like:
gcc -I /xyz myprogram.c
To get at c:/makk/string/strcal.h, you may have to use gcc -I /cygdrive/c/makk/string or, if you know you're actually in that makk directory, you can use -I string (note the lack of leading / since you want a relative path, not an absolute one).
According to g++ -print-search-dirs my C++ compiler is searching for libraries in many directories, including ...
/lib/../lib/:
/usr/lib/../lib/:
/lib/:
/usr/lib/
Naively, /lib/../lib/ would appear to be the same directory as /lib/ — lib's parent will have a child named lib, "that man's father's son is my father's son's son" and all that. The same holds for /usr/lib/../lib/ and /usr/lib/
Is there some reason, perhaps having to do with symbolic links, that g++ ought to be configured to search both /lib/../lib/ and /lib/?
If this is unnecessary redundancy, how would one go about fixing it?
If it matters, this was observed on an unmodified install of Ubuntu 9.04.
Edit: More information.
The results are from executing g++ -print-search-dirs with no other switches, from a bash shell.
Neither LIBRARY_PATH nor LPATH are output from printenv, and both echo $LPATH and echo LIBRARY_PATH return blank lines.
An attempt at an answer (which I gathered from a few minutes of looking at the gcc.c driver source and the Makefile environment).
These paths are constructed in runtime from:
GCC exec prefix (see GCC documentation on GCC_EXEC_PREFIX)
The $LIBRARY_PATH environment variable
The $LPATH environment variable (which is treated like $LIBRARY_PATH)
Any values passed to -B command-line switch
Standard executable prefixes (as specified during compilation time)
Tooldir prefix
The last one (tooldir prefix) is usually defined to be a relative path:
From gcc's Makefile.in
# Directory in which the compiler finds libraries etc.
libsubdir = $(libdir)/gcc/$(target_noncanonical)/$(version)
# Directory in which the compiler finds executables
libexecsubdir = $(libexecdir)/gcc/$(target_noncanonical)/$(version)
# Used to produce a relative $(gcc_tooldir) in gcc.o
unlibsubdir = ../../..
....
# These go as compilation flags, so they define the tooldir base prefix
# as ../../../../, and the one of the library search prefixes as ../../../
# These get PREFIX appended, and then machine for which gcc is built
# i.e i484-linux-gnu, to get something like:
# /usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../i486-linux-gnu/lib/../lib/
DRIVER_DEFINES = \
-DSTANDARD_STARTFILE_PREFIX=\"$(unlibsubdir)/\" \
-DTOOLDIR_BASE_PREFIX=\"$(unlibsubdir)/../\" \
However, these are for compiler-version specific paths. Your examples are likely affected by the environment variables that I've listed above (LIBRARY_PATH, LPATH)
Well, theoretically, if /lib was a symlink to /drive2/foo, then /lib/../lib would point to /drive2/lib if I'm not mistaken. Theoretically...
Edit: I just tested and it's not the case - it comes back to /lib. Hrm :(