Is there a difference between using a makefile and a Makefile?
gmake uses the first "make" file found using the following order:
GNUmakefile, makefile, Makefile
Otherwise, they are semantically equivalent. GNU recommends only using GNUmakefile if you are using GNU extensions.
Source
No, there is none. Even on platforms that have case-sensitive file systems, the 'make' program will look for both names. GNU Make checks for 'makefile' then for 'Makefile' (technically it checks for GNUmakefile first, but you should not need to use that name).
Oops. Should've Googled it.
If a directory has a makefile and a Makefile, gmake will take the makefile in preference.
So. Didn't know about GNUmakefile. Thanks tvanfosson! (-;
Don't know about Gamecat's suggestion as that is the opposite of what I found when I tested.
Thanks florin, your suggestion is what I've found as well now.
makefile then Makefile (superceded by GNUmakefile it seems.)
cheers,
Rob
Related
I have a golang CLI program which generates a makefile to a specific project. While this works, there is an issue when the project already has a makefile. Of course I can check that in advance to avoid collusion, but how is it suggested to do it?
I'm not an expert in makefiles, but how can I create second makefile (maybe with the project name or something) that user can run via make (I guess with additional steps or info to the terminal)
You can generate it as Makefile.project and document to be run as make -f Makefile.project
You can give your Makefile whatever filename. Then make must be executed with parameter -f <your_filename> or --file=<your_filename>. See make manual on filenames.
Which version of make are you using? Some versions run special makefiles before others. For example, GNU make looks for the following files and runs the first one it finds: GNUmakefile, Makefile, makefile.
If you are using GNU make, then name your generated file GNUmakefile and add in the making any makefile already in the directory. That way, anyone running make in the directory will automatically run the generated makefike first.
Does a utility exist to convert a GNU Makefile for gmake to a Makefile that can be used for make (FreeBSD-make)?
That utility is called a developer (programmer, make guru, ...) :-)
Seriously, the AI required for this task is complex enough and the demand for automatic conversion sufficiently close to epsilon that nobody would seriously consider programming one.
If you have a GNU makefile it is best to use GNU make.
As already noted there are no such converter and I very doubt there could exist such. As I understand you have two options:
Use GNU make port to FreeBSD. For example this.
Patch makefiles to make them compatible with FreeBSD make. Actually there are not too much of them in LuaJIT (main Makefile and src/Makefile). This should be rather easy. Just make sure you have all tools (check what is called in shell), and fix "error"s step by step.
For example, error on line 29 (export PREFIX= /usr/local) is due to GNU make directive export which has no similar in FreeBSD make. The manual says "Environment variables are set outside the Makefile in the shell that is running make" and thus you have to comply with this requirement.
Also you'll need to fix all make conditionals and etc, the whole bunch of differences is collected in BSD make vs. GNU make
It is unlikely that there is one because there are things you can do in GNU make that you can't do in other versions of make. Amongst others, the function macros for manipulating strings and the conditionals in the makefile are generally not available.
I want a project to be buildable with both GNU Make (on Linux) and NMake (on Windows). Obviously, I can have the makefiles called Makefile and Nmakefile and build by using make and nmake /F Nmakefile respectively. Is there a pair of names such that make and nmake without -f//F options work?
According to documentation, NMake looks for .mak files, so I've tried to use Makefile.mk and Nmakefile.mak, but it didn't work.
According to the man page of GNU make, it will first look for a file called GNUmakefile.
from man make:
Normally you should call your makefile
either makefile or Makefile. (We
recommend Makefile because it appears
prominently near the beginning of a
directory listing, right near other
important files such as README.) The
first name checked, GNUmakefile, is
not recommended for most makefiles.
You should use this name if you have a
makefile that is specific to GNU
make, and will not be understood by
other versions of make. If makefile
is `-', the standard input is read.
so call your gnu Makefile GNUmakefile
I wanted to create a makefile. So I wrote instructions in a notepad file.
But what extension should I give while saving this file?
If you run:
make
this program will look for a file named makefile in your directory, and then execute it.
If you have several makefiles, then you can execute them with the command:
make -f MyMakefile
By default, The GNU Make tries some particular names, no using any extension. You can specify file with any name to it. But if you want syntax highlighting in some editors, you can use an extension.
There is a wildcard rule for recognizing make files in Geany editor:
Make=*.mak;*.mk;GNUmakefile;makefile;Makefile;makefile.*;Makefile.*;
From the GNU Make documentation
By default, when make looks for the
makefile, it tries the following
names, in order: GNUmakefile, makefile
and Makefile. Normally you should call
your makefile either makefile or
Makefile
These will be searched for if you don't specify the makefile with the -f flag (Only GNU make will look for GNUMakefile, so give it that name only if you know you're using GNU tools)
It sounds like you're running Windows, in which case makefiles often have a .NMK suffix (because they are intended for use with NMAKE). In the civilised world though makefiles do not generally have a suffix: makefile or Makefile are the canonical file names.
If you need to distinguish one from another, and you are configuration managing the makefile, you should use project.make as the name. On the basis that most LSE's , in particular gedit, are recognising this over .mak. Upon packaging, or sign out to a dedicated folder it can be renamed to makefile, the fully qualified path being descriptive of the project. In this way you can have different versions. If your work is complex enough to be using a makefile you should not mixing multiple builds in the same folder anyway.
So there seems to be this problem with GNU Make's $(wildcard) function keeping a directory open on Windows. See (unasnwered) post "make is holding a directory open". Google does not provide much information on the topic.
In short: the Makefile uses the $(wildcard) function at some point, and keeps a directory open, which typically prevents the "make clean" rule to do its work correctly. Re-running "make clean" a second time usually solves it.
I'm using GNU Make version 3.81 under a standard DOS-Box. The author of the post linked to above is using Cygwin.
Has anyone found a fix for this?
Sounds like a file descriptor leak, all right -- harmless for very-short-lived processes (like make) on UNIX, but a right PITA on Windows.
As this is allegedly a bug in make, as opposed to a problem with its usage, it should be addressed first by validating that it still exists when built from source on the newest upstream version, and then by filing a bug report with the GNU make project (or with any distributor with whom you have an appropriate support contract), or diving into the source and attempting to fix it yourself.
It wouldn't hurt to try to reproduce on Linux -- checking for file descriptor leaks are much easier here, as one can just look at /proc/self/fd (or, for a child of make, /proc/$PPID/fd) for things that don't belong.
I did find a workaround for the problem, which at least lets me work in peace.
The problem was that the $(wildcard) function was used to collect the sources files. My clean rule, however, only deletes a directory - no need for the collecting to take please. So I basically put the part of the Makefile that needs to collect the sources files in a conditional statement:
# The clean rule is always parsed
clean:
rm -rf $(OUTPUT_DIRECTORY)
# The compile rule is only interpreted if we did not invoke 'make clean'. We
# can test the value of $(MAKECMDGOALS) for that:
ifeq ($(filter $(MAKECMDGOALS),clean),)
SOURCE_FILES := $(wildcard ...)
compile:
g++ $(SOURCE_FILES) ...
endif