I have a linux makefile that I have to modify so that it compiles on windows with nmake and cl instead of gcc. From what I've seen in the make manual, $^ expands to the dependecy list for that given rule. However, it's not recognized by nmake. Could you please tell me the equivalent windows automatic variable?
(Answered in the comments)
#Etan Reisner wrote:
https://msdn.microsoft.com/en-us/library/cbes8ded.aspx
After reading the Microsoft manual, the OP concluded:
The windows equivalent seems to be $**
Related
I've created a makefile for GNU make 3.80 which works fine on my main development machine running Windows. I've some experience when to use '\' instead of '/' or when a '\\' is applicable.
This time there is '\' in paths as the makefile gets generated from a VS .vxproj via a Perl script.
Strange thing is now that a 100% working makefile behaves different on another machine running exactly the same make.exe binary which is part of my repository.
A rule like this
$(OBJ_DIR)\Atomics.obj : ..\BSW\Atomics\src\Atomics.c
$(CC) $(CFLAGS) $<
on the other machine produces the error message
Cannot open source file: '..BSWAtomicssrcAtomics.c'
OK, solution is make Perl toggle the '\' into '/' when creating the makefile.
But still I wonder if there is some Windows setting which causes this problem?
In a cmd.exe in same directory the same make.exe is called just like:
D:\project\XYZ\make>..\tool\make\make.exe
Yes indeed the presence of some shell binary (msys, mingw, etc.) broke my makefile for the other host. So the only way for my makefile to stick to its MS-DOS commands is to hide the UN*X tools by PATH-settings (e.g. start sub-shell with mini environment).
I want to avoid typing "-std=c++11" on the command line every time.
Is there any simple/direct solution to my question?
If you can, upgrade to GCC 6.
The default mode for C++ is now -std=gnu++14 instead of -std=gnu++98.
You can get a GCC supporting new GCC for example here:
https://nuwen.net/mingw.html
Windows has the DOSKEY command to define macros (which are analogous to Unix aliases).
Something like this should work:
doskey g++="g++ --std=c++11 $*"
A Makefile and the CXXFLAGS variable is an alternative (e.g. see Makefile c++11 support).
In my Makefile, I want to link to a library only if it is installed on the machine. So, for example if the library is hwloc, I want to do the following:
xfoo : foo.o
if (hwloc installed)
gcc foo.o -o $# -lhwloc
else
gcc foo.o -o $#
Is there anyway to do something like this? i.e. Is it possible to check if a specific library is installed and use that as a condition in a Makefile?
Here's the wrong answer:
xfoo : foo.o
if (hwloc installed); then gcc foo.o -o $# -lhwloc; else gcc foo.o -o $#; fi
Commands executed from a Makefile do not have to be just simple, single commands. Anything that a shell can execute, can be invoked from a Makefile. Including an entire script, sandwiched into one line.
Here's the right answer:
However, the above approach is the wrong one. You will find that many free software packages do this kind of thing all the time: conditionally link in a library, if it's available.
But the way that it's done is by running a separate configure script, before running make. Go grab the source tarball to a random free software package, of your choosing, and read the installation instructions. They will all tell you to run the configure script first, before running make.
A crushing majority of free software packages use the GNU toolchain to create their build system -- the configure script, and the Makefile. The GNU toolchain consists of autoconf and automake tools (also libtool in many cases). Go Google these, for more information.
There are also a few other, less popular toolchains, but the GNU toolchain is the most frequently one used, for this sort of a thing. So, to do something along the lines of what you're trying to do, the way this gets typically done is:
In the configure.ac file:
AC_CHECK_LIB(hwloc,some_function_in_the_hwloc_library,[LINK_HWLOC=-lhwloc])
AC_SUBST(LINK_HWLOC)
In the Makefile.am file:
hwloc_LDADD=#LINK_HWLOC#
That's it. That's the way this is done the countless number of times most free software packages need to do this exact same thing. autoconf and automake will take care of writing the shell script and the makefile, that implements this.
I don't have access to a Linux machine at the moment so pardon me my answer will be untested.
I will respectfully disagree with both of my predecessors.
First, using autotools to amend an existing Makefile is a bad idea. Autotools are made to avoid worrying about creating a good Makefile in a simple use case. It's as if OP asked "How to change + to - in my Python script" and the answer was "write a shell script to modify the script, save it in temporary file and execute the file"
Second answer, why do something manually when it can be painlessly done automatically?
So, IMHO the correct answer is, this is the exact use case for $(wildcard):
xfoo: foo.o $(wildcard libhwloc.a)
gcc $(patsubst lib%.a, -l%, $^) -o $#
Note: the library is installed or not ahead of time but not to be made during the build.
If you don't want to get involved with the autotools/etc. for this (which while a reasonable solution is also reasonable to want to avoid for something this simple) and you don't want to have to play guessing games about where people may or may not have this hwloc library installed then the best you can do is to let people turn the feature on manually.
Use three (or four) make variables. USE_HWLOC, HWLOC_LDLIBS, HWLOC_CFLAGS and possibly HWLOC_LDFLAGS.
Then when USE_HWLOC is defined you link against the library and use the other three variables in case they have also been set.
ifdef USE_HWLOC
HWLOC:=-lhwloc
else
HWLOC:=
HWLOC_LDLIBS:=
HWLOC_LDFLAGS:=
HWLOC_CFLAGS:=
endif
xfoo : foo.o
gcc foo.o -o $# $(HWLOC_LDLIBS) $(HWLOC)
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
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