Are there any? I'd like to have one makefile handle all the build targets across platforms.
MinGW and GNU are the same. Both use GNU Make (go figure!). There are options for Cygwin, including GNU make, cmake and possibly others. If you go with the same make, then you have a starting point for portable Makefiles. However ...
Makefile recipes often include OS-specific commands as each line in a recipe is handed off to the OS command shell for execution.
The tools available under a specific OS may vary.
Paths are always a bit of a challenge.
Cygwin and MinGW each provide environments that attempt to mimic UNIX and make the issues above easier to deal with.
Related
Is it possible to switch from Clearmake to GNU make at a certain point in a build and then switch back? If so, how so?
Note, neither GNU make nor clearmake are compilers.
All make versions are just tools for running other commands, so you can just write a rule that will run a different make as a command:
run-make:
gmake do-something
Now when the run-make rule is invoked it will call GNU make (here called gmake, but it might be called make or whatever) to build a target do-something. Once that's done it'll return back to the current make version (presumably clearmake).
With the minimal information you provided, that's the best we can do.
While looking at my friend's Makefile, I noticed that he used the install shell command. From what I can tell, the command allows you to install and chmod files with one fell swoop. The command came up in a subsequent conversation of ours, and he said he had heard that the command is considered somewhat archaic, and that developers should use cp, mv, chmod etc. for modern projects.
Strangely, this has been my only encounter with the command. This leads me to believe that the command has indeed been rejected and hence forgotten. Is this true? Is there some sort of security flaw with the program? From my possibly naive point of view, using a single command is always better than using many commands
I suspect the answer is that the install command is pretty much only used in scripts and makefiles (such as the automake makefiles that #Jack Kelly describes), and almost never interactively. Thus people rarely see it 'over someone's shoulder', and it doesn't lodge in their consciousness.
It is however, as you say, pretty much exactly the right tool for this job. The problem is that it's not a POSIX command, so it's wise not to use any terribly exotic options. The version of it used in automake makefiles is supplemented by a distributed shell script if the configure script hasn't convinced itself that the local version is sufficiently compatible.
See the autoconf manual's discussion of portable shell scripting, for some useful tips on this general topic.
Makefiles generated by automake still use it, as evidenced by the line (or similar):
checking for a BSD-compatible install... /usr/bin/install -c
in the output of configure.
git-slave documentation only has the following not-so-helpful comment regarding installation on Windows:
* Limited windows support
Multiple users have been successful in using gitslave with Windows.
This is "supported" only in the sense that people have reported it to
work and we accept bugfixes, not that you can `make` install or check,
or that it is QAed on this platform prior to release."
When I try to download and run 'nmake install' I get the equally cryptic error:
makefile(2) : fatal error U1001: syntax error : illegal character '{' in macro
Stop.
Does anyone have any experience with this and can point me in the right direction?
The Makefile for git-slave has only been used with GNU Make - as it is a rather simple makefile, there is no reason it shouldn't work with Microsoft nmake as well, except for "gratuitous" use of Make extensions that are not supported by Microsoft nmake. ( How similar/different are gnu make, microsoft nmake and posix standard make? has a good summary of the differences).
On lines 2-4 of gitslave/Makefile, if you replace ${prefix} with $(prefix) and ${mandir} with $(mandir) [essentially replace braces with parentheses (brackets)] nmake should no longer choke on Makefile. However, unless you have installed a bunch of POSIX utilities or something that allows commands like mkdir -p, rm -f, and sed to work, fixing the nmake incompatibility would only allow (at best) make testcheck to work.
None of the gitslave developers have regular(?) access to Windows development machines, so like the documentation says: "we accept bugfixes, [but do] not [claim] that you can make install or check,
or that it is QAed on this platform."
I imagine that the other people who have used git-slave on windows just made sure that Perl and gitslave and any POSIX utilities that gitslave depends on (e.g. grep and rm) are installed somewhere in PATH.
On Windows you can download and install the free unix tool kit including all necessary programs:
https://sourceforge.net/projects/unxutils/
You also need a perl tool kit because "pod2man" is used in the make process.
Furthermore the script "gits" is a perl script which runs under *ix because of the "she-bang" instruction in the first line ("#!/usr/bin/perl") - this doesn't work on Windows.
I created a small wrapper batch scripts that uses my perl to start the original script:
gits.bat:
perl gits %*
Hope this helps.
I'm using Mingw to build a C/C++ project. This project has makefiles beyond my comprehension, and relies on a custom and quite sophisticated toolchain to compile it. It's quite convenient to have GNU tools available on Windows, especially from Windows's cmd shell, but while invoking the tools (make in particular), MinGW seems to change my PATH around.
Cmd does it normally:
echo %PATH% > ... c:\Apps\msys\bin ... (from cmd)
but msys changes this address to :
echo $PATH > ... /usr/bin ...
in msys, even when I print the PATH from a makefile. As a result, make complains that it can't find commands like make, uname, echo, you name it (no pun intended).
Strangely, I managed to get this environment working ages ago without a hitch, but this is the first time I remember seeing this path problem. How can I get MinGW/msys to correctly point to its executables?
richard has a point - there were two different shells fighting over environment variables (not to mention running msys) and so each parsed its own and the system's environment variables differently.
Also make sure that variables defined in your user or system environment are properly written - Windows likes "C:\foo\bar" style paths, but Msys treats them as "/c/foo/bar".
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.