Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 3 years ago.
Improve this question
I have a Makefile on my Linux Pc.I want to build and run the same program on MacOS too . How to edit the following Makefile ?
I want to compile a C program that has a header file of a graphics library EGGXProCALL JAXA "eggx.h".
I already installed Xcode ,XQuartz.
I have installed EGGX file on the following directory .
[Home#/opt/eggx]$
I have a C file in the following directory.
[Home#~/Desktop/development]$
I have checked the followings .
① gcc works fine here [Home#~/Desktop/development]$
② even the sample program to display a digital clock works ,
when the current directory is [Home#/opt/eggx]$
③ PROBLEM
when I tried to build [make] the program from [Home#~/Desktop/development]$ by using the makefile that I had in Linux.
I always get the following error message.
[Home~/Desktop/development]$ sudo make
gcc -c main.c
main.c:7:10: fatal error: 'eggx.h' file not found
#include <eggx.h>
^~~~~~~~
1 error generated.
make: *** [main.o] Error 1
[Home#~/Desktop/development]$
Here is the Makefile
# Makefile
OBJS = main
$(OBJS): $(OBJS).o
# gcc -O2 -Wall $(OBJS).c -o $(OBJS) -I/usr/local/include -L/usr/local/lib64 -leggx -lX11 -lm
gcc $(OBJS).c -o $(OBJS) -I/usr/local/include -L/usr/local/lib64 -leggx -lX11 -lm
$(OBJS).o: $(OBJS).c
gcc -c $(OBJS).c
.PHONY: clean
clean:
rm -f $(OBJS) $(OBJS).o
You must do things in the correct order and not proceed to the next step until you have correctly completed the previous step.
1. Download, and extract the library.
The download is normally done with git clone or scp to copy the source files from somewhere.
The extract (unpack from archive) is normally done with:
tar -xvf eggx-0.93r5.tar
That will normally create a new directory (with the same name as the tar-file but without the .tar extension) like:
eggx-0.93r5
2. Build the library.
Normally you need to change directory into the newly created one and run make. I gave you the Makefile last time so you need to do:
cd eggx-0.93r5
cp MAKEFILEFROMMARK Makefile
make
There should be no errors. If there are errors, you must solve them and then run:
make clean # delete any rubbish from previous failed build
make
3. Install the library.
You normally do this with:
make install
What that actually does depends on the package you are installing, but as a general rule, it will copy the header files and the libraries you just made into a "known" location, like /usr/local or /opt/package. The idea is to make all the files your own code will need available to all users of the computer by "publishing" or installing them to known locations.
4. Work out how to compile a simple C program that uses the library.
You should do the following steps in a completely different directory from where you downloaded the library to - do not mix your code with the library's code.
If your program uses eggx.h like this:
#include "eggx.h"
then you need to find where eggx.h is like this:
find /usr /opt /Users -name eggx.h
If that results in:
/path/to/somewhere/include/eggx.h
that means you must add this to your gcc command to tell the compiler how to find it:
gcc -I/path/to/somewhere/include ...
If your library is called libeggx.a, you need to find that too:
find /usr /opt /Users -name "libegg*a"
If that results in:
/path/to/somewhere/lib/libeggx.a
that means you need to add this to your gcc command to tell the linker where it is and what it is called:
gcc ... -L/path/to/somewhere/lib -leggx
If your program uses X11, you must install XQuartz on a Mac, and add the flags/switches for X11 into your compilation:
gcc ... -I /opt/X11/include -L /opt/X11/lib -lx11 ...
So, putting all that together, if your program is called program.c, you will compile and link with:
gcc program.c -o program -I/path/to/somewhere/include -I /opt/X11/include -L /opt/X11/lib -lx11 -L/path/to/somewhere/lib -leggx
and then run with:
./program
5. Make a Makefile that enshrines what you learned at (4).
That might look something like this:
EGGINC = -I /path/to/somewhere/include
EGGLIB = -L /path/to/somewhere/lib -leggx
X11INC = -I /opt/X11/include
X11LIB = -L /opt/X11/lib -lx11
$(OBJS): $(OBJS).o
gcc $(OBJS).c -o $(OBJS) $(EGGLIB) $(X11LIB)
$(OBJS).o: $(OBJS).c
gcc -I/usr/local/include $(EGGINC) $(X11INC) -c $(OBJS).c
You build your program in two steps:
Build the source file into an object file
Link the object file with libraries to create the final executable program
The preprocessor (which handles #include directives) is part of the building of the object file. So all flags that are needed for creation of the object files (like the -I option) should be present there and only there.
So the two rules could be changed as follows:
$(OBJS): $(OBJS).o
gcc $(OBJS).c -o $(OBJS) -L/usr/local/lib64 -leggx -lX11 -lm
$(OBJS).o: $(OBJS).c
gcc -I/usr/local/include -c $(OBJS).c
Of course that assumes that the EGGX library was installed in /usr/local.
when I am running this .bat file on command prompt it is throwing an error i.e "The filename, directory name or volume label syntax is incorrect".
Batch file contains--
nmake /nologo /f makefile /a
pause
makefile contains the following:
# nmake makefile to build a sample ADK MAC compliant application
# NOTE: EOSSDK is needed to resolve ADK Library references and header file includes
VRXSDK = C:\eVoAps\SDK\1.2.0\VRXSDK
#VXEOS = C:\eVoAps\EOSSDK\2.1.4
ADK = C:\eVoAps\ADK
VSFSTOOL = C:\Program Files\VERIFONE\FST
VRXIncludes = $(VRXSDK)\include
ADKIncludes = $(ADK)\VRX\Include
EOSIncludes = $(EOSSDKNEW)\include\ssl2
IncDir = .\Source
SrcDir = .\Source
ObjDir = .\Objects
OutDir = .\Download
EOSObjects = C:\eVoAps\SDK\1.2.0\EOSSDKNEW\lib
Includes = -I$(IncDir) -I$(VRXIncludes) -I$(EOSIncludes) -I$(ADKIncludes) -I$(SrcDir)
# Compiler options
# Ignoring warning 1295 - Deprecated declaration - give arg types
# Defiing _VRXEVO for Verix specific code in the sample.
COptions = -vsoapp -g -p -armcc,"--diag_suppress 1295" -D _VRXEVO -DLOGAPI_ENABLE_DEBUG -DVFI_GUIPRT_IMPORT -DVFI_MAC_DLL_IMPORT -DVFI_IPC_DLL_IMPORT -DVFI_SYSINFO_DLL_IMPORT -DVFI_SYSBAR_DLL_IMPORT
LinkOptions = -vsoapp -g -p
# NOTE: elog.o required to resolve references in the ADK libs. Log lib requires STL
# LibVFIMac only needed to resolve sysShowDesktop()
# svc_net.o required for mac library....
Libs = $(ADK)\vrx\lib\libvfiguiprt.so \
$(ADK)\vrx\lib\libvfiipc.so \
$(ADK)\vrx\lib\liblog.so\
$(ADK)\vrx\lib\libvfimac.so \
$(VRXSDK)\lib\vxstl.so \
$(EOSSDKNEW)\lib\svc_net.o \
$(EOSSDKNEW)\lib\elog.o
AppObjects = $(ObjDir)\BossApp.o
$(OutDir)\BossApp.vsa.p7s : $(OutDir)\BossApp.vsa
"$(VSFSTOOL)\FST" BossApp.fst
$(OutDir)\BossApp.vsa : $(AppObjects)
$(VRXSDK)\bin\vrxcc $(AppObjects) $(Libs) -o $#
$(VRXSDK)\bin\vrxhdr -s 128000 -h 128000 -l ELOG.LIB=N:/ELOG.LIB -l NET.LIB=N:/NET.LIB
$(OutDir)\BossApp.vsa
###### Compile #######
$(ObjDir)\BossApp.o : $(SrcDir)\BossApp.cpp
$(VRXSDK)\bin\vrxcc -c $(Includes) $(COptions) -o $(ObjDir)\BossApp.o $(SrcDir)\BossApp.cpp
I am unable to figure out what i'm missing here.Please help me.
This will likely be the reason for a very low % of people but I was getting this error from any .BAT file on my machine (happened to be Windows Server 2019). In my case I was getting the error because I had recently installed ConEmu (console replacement app) and had it set for Integration mode (where it replaces the normal CMD app) and it was failing to launch .BAT files correctly. Once I turned off Integration mode for ConEmu my .BAT files started working again.
This procedure is not written in windows batch. It needs to be written in windows batch language to be processed by cmd.exe.
I am working in this project that requires me to use some software that was written a long time ago and is now open sourced and can be found at http://www.wotug.org/occam/compilers/oc/oc-src.tar.gz. The software is basically a compiler for Occam.
When I unpack the tar.gz I find a source folder that has a csh script to build the software.
#!/bin/csh -f
#
# Quick build script for occam compiler and libraries
#
# You will need to redefine these
set gccinclude = "/u/products/toolset/release/build/include/gcc"
set inmos_occam = /inmos/prod/d4205a
# These should be ok
set base_dir = $cwd
set path = ($inmos_occam/tools $base_dir/preocc $path)
setenv ISEARCH "$base_dir/libs/ $base_dir/include/ $gccinclude/"
set buildlibs = (arglib extlib tcofflib)
foreach buildlib ($buildlibs)
echo --- $buildlib
cd $buildlib
make -f [Mm]akefile.s4 COMMON=$base_dir GCCINCLUDE=$gccinclude TLIB=
cd ..
end
... some other stuff...
I believe the lines:
set gccinclude = "/u/products/toolset/release/build/include/gcc"
set inmos_occam = /inmos/prod/d4205a
specify where the .h files are stored for the compilation process and the inmos_occam variable tells where I would like the final binary to be stored, so I changed them to:
set gccinclude = "/usr/include"
set inmos_occam = ./bin
The problem is that when I run the script I get the following errors:
--- arglib
gcc -I./ -nostdinc /usr/include ./arg.c -c -o arg.o -ansi -DSUN4
./arg.c:9:19: fatal error: ctype.h: No such file or directory
#include <ctype.h>
^
compilation terminated.
make: *** [arg.a] Error 1
--- extlib
gcc -c -msoft-float -Wall -ansi -pedantic -nostdinc /usr/include I/home/andres/Documents/T2015-Compiler/src/include -DGNU extconv.c
In file included from /home/andres/Documents/T2015-Compiler/src/include/extlib.h:8:0,
from extconv.c:1:
/home/andres/Documents/T2015-Compiler/src/include/imsstd.h:30:19: fatal error: stdio.h: No such file or directory
#include <stdio.h>
....and a lot more....
I dont know much about GCC, but I believe the problem is that the argument '-nostdinc' tells the compiler to not look in the standard include directories (where the files are in my ubuntu system) and that is why it is not working. However, I do not how to overwrite this behaviour. I would greatly appreciate help so that I can compile this, also if you believe this is not the cause of the problem, please do let me know.
Thanks!
-nostdinc means that you are ignoring the standard include path, which I'm guessing you don't want. However I can see:
gcc -I./ -nostdinc /usr/include ./arg.c -c -o arg.o -ansi -DSUN4
/usr/include should be like -I/usr/include in order to include that to the include path.
Later you have
I/home/andres/Documents/T2015-Compiler/src/include
which should be
-I/home/andres/Documents/T2015-Compiler/src/include
I'm trying to cross compile OpenSSL for PowerPC with the FIPS module. My build host's architecture is not PowerPC. I was able to cross compile the FIPS module just fine. However, when I run make on openssl, during the linking phase, it tries to execute certain binaries to run tests. The issue is that those binaries are produced for the target architecture and, as a result, I get the error "cannot execute binary file". Is there a way to produce executables of these tests on the host architecture rather than the target architecture? Should I be handling this process differently? Here are the following commands I used to build openssl. I replaced certain directories with DIR_HIDDEN.
export FIPS_DIRECTORY="$PWD/../../openssl-fips/tgt/linux-ppc603e/"
export cross="DIR_HIDDEN/powerpc-linux-gnu-"
make clean || exit 1
make dclean || exit 1
./Configure --prefix=$PWD/../tgt/linux-ppc603e linux-ppc fips --with-fipsdir=${FIPS_DIRECTORY}
make depend || exit 1
make CC="$FIPS_DIRECTORY/bin/fipsld" RANLIB="${cross}ranlib" AR="${cross}ar r" LD="$FIPS_DIRECTORY/bin/fipsld" FIPSLD_CC="${cross}gcc" HOSTCC="/usr/bin/gcc" || exit 1
make install || exit 1
I get the following error during the make command:
shlib_target=; if [ -n "" ]; then \
shlib_target="linux-shared"; \
elif [ -n "libcrypto" ]; then \
FIPSLD_CC="/DIR_HIDDEN/openssl/openssl-1.0.1i/../../openssl-fips/tgt/linux-ppc603e//bin/fipsld"; CC=/DIR_HIDDEN/openssl/openssl-1.0.1i/../../openssl-fips/tgt/linux-ppc603e//bin/fipsld; export CC FIPSLD_CC; \
fi; \
LIBRARIES="-L.. -lssl -L.. -lcrypto" ; \
make -f ../Makefile.shared -e \
APPNAME=openssl OBJECTS="openssl.o verify.o asn1pars.o req.o dgst.o dh.o dhparam.o enc.o passwd.o gendh.o errstr.o ca.o pkcs7.o crl2p7.o crl.o rsa.o rsautl.o dsa.o dsaparam.o ec.o ecparam.o x509.o genrsa.o gendsa.o genpkey.o s_server.o s_client.o speed.o s_time.o apps.o s_cb.o s_socket.o app_rand.o version.o sess_id.o ciphers.o nseq.o pkcs12.o pkcs8.o pkey.o pkeyparam.o pkeyutl.o spkac.o smime.o cms.o rand.o engine.o ocsp.o prime.o ts.o srp.o" \
LIBDEPS=" $LIBRARIES -ldl" \
link_app.${shlib_target}
make[2]: Entering directory `/DIR_HIDDEN/openssl/openssl-1.0.1i/apps'
( :; LIBDEPS="${LIBDEPS:--L.. -lssl -L.. -lcrypto -ldl}"; LDCMD="${LDCMD:-/DIR_HIDDEN/openssl/openssl-1.0.1i/../../openssl-fips/tgt/linux-ppc603e//bin/fipsld}"; LDFLAGS="${LDFLAGS:--DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DB_ENDIAN -DTERMIO -O3 -Wall -DOPENSSL_BN_ASM_MONT -I/DIR_HIDDEN/openssl/openssl-1.0.1i/../../openssl-fips/tgt/linux-ppc603e//include -DSHA1_ASM -DSHA256_ASM -DAES_ASM}"; LIBPATH=`for x in $LIBDEPS; do echo $x; done | sed -e 's/^ *-L//;t' -e d | uniq`; LIBPATH=`echo $LIBPATH | sed -e 's/ /:/g'`; LD_LIBRARY_PATH=$LIBPATH:$LD_LIBRARY_PATH ${LDCMD} ${LDFLAGS} -o ${APPNAME:=openssl} openssl.o verify.o asn1pars.o req.o dgst.o dh.o dhparam.o enc.o passwd.o gendh.o errstr.o ca.o pkcs7.o crl2p7.o crl.o rsa.o rsautl.o dsa.o dsaparam.o ec.o ecparam.o x509.o genrsa.o gendsa.o genpkey.o s_server.o s_client.o speed.o s_time.o apps.o s_cb.o s_socket.o app_rand.o version.o sess_id.o ciphers.o nseq.o pkcs12.o pkcs8.o pkey.o pkeyparam.o pkeyutl.o spkac.o smime.o cms.o rand.o engine.o ocsp.o prime.o ts.o srp.o ${LIBDEPS} )
/DIR_HIDDEN/openssl/openssl-1.0.1i/../../openssl-fips/tgt/linux-ppc603e//bin/fipsld: line 185: ./openssl: cannot execute binary file
make[2]: *** [link_app.] Error 126
When invoking the make command again and again, I get the same error but for all the applications located in the /test directory of the openssl tarball. Examples include bntest, ectest, and ecdhtest.
I received a similar error when I was cross compiling the FIPS module, but I was able to resolve that by including the host compiler in the HOSTCC variable. A similar trick did not work for the openssl compilation.
Any guidance would be appreciated. Thanks!
I was able to modify the make command to get the process to complete. I was missing the FIPS_SIG environment variable, which points to the incore script. The make command is now:
make FIPS_SIG=$PWD/`find ../../openssl-fips/ -iname incore` CC="$FIPS_DIRECTORY/bin/fipsld" RANLIB="${cross}ranlib" AR="${cross}ar r" LD="$FIPS_DIRECTORY/bin/fipsld" FIPSLD_CC="${cross}gcc"
I still see prints to console that indicate that openssl cannot be executed, but these are warnings and don't halt the makefile. Not really sure why or how this fixed the problem, but I'll take it.
I have a simple C program (one source file) which I want to compile on Linux and on Windows via make and nmake, respectively. Is there a possibility to accomplish this with a single makefile?
I thought about something like
ifeq($(MAKE), nmake)
// nmake code here
else
// make code here
endif
Unfortunately nmake seems not to understand ifeq, so I cannot use that. I have a working makefile, but that produces very ugly results:
hello: hello.c
$(CC) hello.c
That works on both systems. The problem is that the outcome depends on the default behaviors of the respective compilers. Under Linux I get an executeable named 'a.out' rather than 'hello'. Under Windows I get 'hello.exe' but there is also 'hello.obj' which I do not want to have.
Is there an alternative way? Or is what I'm trying absolutely impossible?
It's probably not impossible, but most likely so hard that it would be easier to write two makefiles anyway.
Both GNU make (used in Linux) and nmake have include directives though, so some common things can be put in a common makefile that is included by the main makefile.
You should look at using CMake for this. With one source file, it should be quite easy. Here is how you could set up a simple project:
cmake_minimum_required(VERSION 3.10)
# set the project name
project(Hello)
# add the executable
add_executable(Hello hello.c)
To build the simple project, you would do the following (this assumes your source and CMakeLists.txt files are in the same directory as the source file hello.c:
mkdir build
cd build
cmake ..
cmake --build .
I wanted to use the same makefile include to be used by Make and NMAKE. Since make recognises line continuation on comment lines, but NMAKE doesn't, this means that we can have separate instructions for Make and NMAKE. For example:
# NMAKE code here \
!ifndef 0 # \
MV=move # \
RM=del # \
CP=copy # \
!else
# Make code here
MV=mv -f
RM=rm -f
CP=cp -f
# \
!endif
You just have to make sure that NMAKE-specific code is encompassed by # \.
I am not able to find a way to use a common makefile to work for both GNU Make and Microsoft NMAKE, mainly because they have an incompatible syntax for "include" and/or "if" directives. Microsoft NMAKE requires to use ! prefix for directives. For example, !if, !include, etc...
If it is allowed to have separate macros, however, it could be tricked around. Here I presents the best way I found so far for making a makefile compatible for both GNU Make and Microsoft NMAKE by observing the followings:
Microsoft NMAKE reads TOOLS.ini file for default macros.
The Microsoft suite uses .obj as the object file extension.
GNU Make reads files defined in a MAKEFILES environment variable.
The GNU suite use .o as the object file extension.
GNU make need not give an executable extension .exe for a target.
Note: The following has been tested using Microsoft Visual Studio 2015 and MINGW32.
Step 1: create a following DOS batch file and let it run whenever the CMD prompt is invoked.
set MAKEFILES=TOOLS.gcc
call "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat"
Step 2: Create a TOOLS.ini file under your working directory as below: (this file is independent of your project dependencies except the libraries possibly)
[NMAKE]
LDLIBS =
CDEBUG = /Zi
LDEBUG = /debug:full
WDFLAGS = /wd4996 /wd4774 /wd4018 /wd4710 /wd4820
CFLAGS = /nologo $(CDEBUG) /EHsc /Wall $(WDFLAGS)
LDFLAGS = /nologo $(LDEBUG)
RM = del /F /Q
LINK = "$(VCINSTALLDIR)bin\link" $(LDFLAGS)
CP = copy
CC = cl
CPP = $(CC) /P
X = .exe
O = .obj
.obj.exe:
$(LINK) $** $(LOADLIBES) $(LDLIBS) /Out:$#
Step 3: Create a TOOLS.gcc under your working directory as below: (this file is independent of your project dependencies except the libraries possibly)
LD_LIBS =
LDLIBS =
CDEBUG = -g
LDEBUG = -g
CFLAGS = $(CDEBUG)
LDFLAGS = $(LDEBUG)
RM = rm -f
LINK = gcc $(LDFLAGS)
CP = cp
CC = gcc
CPP = $(CC) -E
X =
O = .o
%: %.o
$(LINK) $^ $(LOADLIBES) $(LDLIBS) -o $#
Step 4: Edit your makefile as below (note $(X) and $(O)) where only dependencies are specified.
SHELL = /usr/bin/sh
app: app1$(X) app2$(X)
app1$(X): app1$(O)
app2$(X): app2$(O)
clean:
$(RM) *.exe *.o *.obj *.ilk *.pdb *.tmp *.i *~
Step 5: Enjoy GNU Make and Microsoft NMAKE with the same makefile
$ nmake
$ make clean
$ nmake clean
$ make
My solution is to use two different filenames. (since the Makefile name searching priority in different OSes will not be the same)
For Windows, I use normal "Makefile."
For Linux, I use the special "GNUmakefile" according to this article.
So that nmake (Win) will find "Makefile," and make (Linux) will find "GNUmakefile."
Solution: https://github.com/jaykrell/w3/blob/master/Makefile
# This one Makefile works with Microsoft nmake and GNU make.
# They use different conditional syntax, but each can be
# nested and inverted within the other.
all: default
ifdef MAKEDIR: # gmake: false; nmake: unused target
!ifdef MAKEDIR # gmake: not seen; nmake: true
#
# Microsoft nmake.
#
!else # and now the other
else
#
# GNU (Posix?) make.
#
endif # gmake: close condition; nmake: not seen
!endif : # gmake: unused target; nmake close conditional
default: # default target for both
I just thought of something completely different.
If you stick to your extremely simple Makefile, which, you say, works, and just put the 'standard' variables CC and CFLAGS in your respective environments, say
export CC=gcc
respectively
set CC=CL.EXE
and
export CFLAGS=-o myexecutable
respectively
set CFLAGS=/out:myexecutable.exe
it might just work.
Be aware, I'm not firm in the exact options to use, you'll have to figure them out yourself. But AFAIK both make variants recognize the same set of flags. You may even set those on the respective command lines (but not in the makefile, since NMAKE uses a different 'ifeq' syntax...)
Yes, you can do this with a single Makefile. The best source for this material is the O'Reilly book:
Managing Projects with GNU Make, Third Edition By Robert Mecklenburg
See chapter 7: Portable Makefiles.
In summary, the technique is to test the environment variable ComSpec which says if the Windows command interpreter is present:
ifdef COMSPEC
MV ?= move
RM ?= del
else
MV ?= mv -f
RM ?= rm -f
endif
I wrap this with a portable shell script which uses sed to edit the makefile for Nmake or GNU make...
I've recently experimented with using the C preprocessor to generate a portable Makefile from a template Makefile.cc containing preprocessor symbols. So far it's worked surprisingly well. The first observation is that NMAKE will prescan a Tools.ini file, which I provide in the same directory as
[NMAKE]
MAKECONFIG=-D_NMAKE
Then I have a 'true' Makefile next to it which is written in only the common sub language of GNU Make and NMAKE.
MAKEFILE=Makefile.mk
TEMPLATE=Makefile.cc
all: $(MAKEFILE)
$(MAKE) -f $(MAKEFILE)
clean: $(MAKEFILE)
$(MAKE) -f $(MAKEFILE) clean
$(MAKEFILE): $(TEMPLATE)
$(CXX) $(MAKECONFIG) -E $(TEMPLATE) > $(MAKEFILE)
Note that the -E switch is pretty common for compilers (at least the big three I work with: GCC, Clang, and CL) for only preprocessing the file. With GNU Make the $(MAKECONFIG) expands to nothing, but in NMAKE it provides the preprocessor variable declaring itself. Since your template Makefile.cc can check it with #ifdef, as well as check for common variables with which the compiler declares itself, you can customize your Makefile.mk quite a bit for both the 'make' program, your operating system, and the compiler you're using.
If you have any 'make' you probably already have a C compiler too; there's no need to install additional software like CMake or autotools. It uses mechanisms that are old and so likely to work in a lot of environments. And from what I've been able to tell so far, it's really fast. Faster at least than running a configuration step in autotools. The only disadvantage I've faced is that it limits the style of your Make rules to being on the same line, because the preprocessor changes the indentation of the code. Also the preprocessor spits out lines with # tags, but since these start a comment in a Makefile, they get ignored anyway.
A have a somewhat small C++ project with a Makefile.cc that looks like the following snippet. It compiles on GNU Make or NMAKE with either GCC, Clang, or CL and on either Windows or in a POSIX environment. I've yet to support BSD Make or test any other compiler though.
// Make Version
#ifdef _NMAKE
# define ifdef !ifdef
# define ifndef !ifndef
# define else !else
# define endif !endif
# define err(x) !error x
# define cat(x, y) x=$(x) y
#else // GNU Make
# define err(x) $(error x)
# define cat(x, y) x += y
#endif
// System Commands
ifdef SHELL
RM=rm -f
else
ifdef COMSPEC
RM=del /f
else
err("Cannot determine your system commands.")
endif // COMSPEC
endif // SHELL
// Project Variables
STD=c++17
SRC=test.cpp dbg.cpp dir.cpp dll.cpp env.cpp err.cpp fifo.cpp file.cpp shm.cpp sig.cpp socket.cpp sys.cpp xdg.cpp
BIN=test
.SUFFIXES: .cpp .hpp .o .d .obj .pdb .lib .exp .ilk .log .i .db
// Operating system
#ifdef _WIN32
cat(CFLAGS, -D_WIN32)
EXE=$(BIN).exe
#else
cat(CFLAGS, -D_POSIX_C_SOURCE)
cat(LDFLAGS, -ldl -lrt -lpthread)
EXE=$(BIN)
#endif
// Make Targets
all: $(EXE)
clean: ; $(RM) $(EXE) *.o *.d *.obj *.pdb *.lib *.exp *.ilk *.log *.i
// Compiler Options
#ifdef _MSC_VER
cat(CFLAGS, -nologo -std:$(STD) -W4 -DNOMINMAX -D_CRT_SECURE_NO_WARNINGS -EHsc -permissive-)
ifndef NDEBUG
cat(CFLAGS, -Zi)
endif
cat(LDFLAGS, -nologo)
OBJ=$(SRC:.cpp=.obj)
$(EXE): $(OBJ); $(CXX) $(LDFLAGS) $(OBJ) -Fe$#
.cpp.obj: ; $(CXX) $(CFLAGS) -c $<
#elif defined(__GNUC__) || defined(__llvm__) || defined(__clang__)
cat(CFLAGS, -std=$(STD) -Wall -Wextra -Wpedantic -MP -MMD)
ifndef NDEBUG
cat(CFALGS, -g)
endif
cat(LDFLAGS, -rdynamic)
OBJ=$(SRC:.cpp=.o)
$(EXE): $(OBJ); $(CXX) $(LDFLAGS) $(OBJ) -o $#
.cpp.o: ; $(CXX) $(CFLAGS) -c $<
# ifndef _NMAKE
-include $(SRC:.cpp=.d)
# endif
#else
# error "Cannot determine your compiler."
#endif
Wouldn't it be possible to use a script in gnu sed, or perl to translate the host's Makefile to a Microsoft compatible NMakefile? The Makefiles, after all, are text files to provide input for whichever helper tool you're using. Sed and Perl both exist for Linux and Windows.