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
Related
In Unix Makefile I can prefix a recipe line with - to ignore any error that will occur (as describe in Errors in Recipes).
hello_world: hello_world.cxx
-$(CXX) $(CXXFLAGS) $^ -o $#
I converted my Makefile to CMake:
cmake_minimum_required(VERSION 3.0)
project(HelloWorld)
add_executable(hello_world hello_world.cxx)
and run cmake and the generated Makefile looking fine, except the missing -.
Is it possible to generate Unix Makefile with CMake that will ignore errors (prefix the recipe line with -)?
The best would be to specify it per target level. I know I can run make -i to have the same behaviour but it isn't that convenient.
You cannot.
make is designed to give the user a fine control over commands it runs. CMake's under-the-hood commands are supposed to always succeed.
As a hack, you can generate makefiles and run make --ignore-errors.
But I advice making each of your examples that would fail a separate project, and run them from an external script.
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.
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
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