I am currently developing a C++ command line utility to be distributed as an open-source utility on Github. However, I want people who download the program to be able to easily compile and run the program on any platform (specifically Mac, Linux, and Windows) in as few steps as possible. Assuming only small changes have to be made to the code to make it compatible with the various platform-independent C++ compilers (g++ and win32), how can I do this? Are makefiles relevant?
-
5I know that there's plenty of build systems out there, I still like CMake because of the broad support. If you use QT anyway, then qmake seems make sense. I have also had some good experiences with premake. In the end it's up to your discretion which tool you prefer. There's a lot of them out there, you can always take a look at the [Wikipedia list](http://en.wikipedia.org/wiki/List_of_build_automation_software) if you feel like your current tool just doesn't cut it. – PeterT Jul 27 '13 at 23:22
-
Which parts of your code *may* be platform dependent? Graphics? File paths? Libraries? – Jongware Jul 27 '13 at 23:23
-
File Paths for sure. It is a command line utility, so graphics aren't an issue. As for libraries, these are my include statements:`#include
#include – danielmhanover Jul 27 '13 at 23:25#include #include #include using namespace std;` -
Isn't CMAKE a bit overkill, since I am not using any platform-dependent libraries? – danielmhanover Jul 27 '13 at 23:26
-
@DanielH. I use build generation tools primarily to generate platform and compiler dependent "make files" for most systems it's going to be makefiles but most guys using VC++ still prefer their `*.vcproj`/`*.vcxproj` files. – PeterT Jul 27 '13 at 23:32
-
1To expand on @PeterT's comment, you can check out meta build systems like CMake and Premake. The idea is write and maintain one build script regardless of target platform. You then use that build script to generate target specific makefiles or project files that are then fed to the build tool. – greatwolf Jul 28 '13 at 00:16
-
What do my users need installed on their machine for premake to work for them? – danielmhanover Jul 28 '13 at 00:59
-
1@DanielH. they'll need premake itself since the build script can't work without it. Just like a makefile won't do anything by itself without the make tool. Last I checked, premake isn't that big though so you can probably just include it with your project for convenience. – greatwolf Jul 28 '13 at 02:43
2 Answers
My advice is, do not use make files, maintaining the files for big enougth projects is tedious and errors happen sometimes which you don't catch immediatly (because the *.o file is still there).
See this question here
-
While I agree with you for larger projects, mine is very simple and easy to maintain and I do not want my users to have to install new software (such as Python, for SCons) just to run my utility. – danielmhanover Jul 27 '13 at 23:47
-
Please show some evidence of that. (The equivalent of) Makefiles are the de fact industry standard. `make` may be relative basic but it’s still an integral part of the C++ tool chain and a good choice. – Konrad Rudolph Jul 27 '13 at 23:47
-
1because it happend to me, its so easy to forget to change some stupid requirements for your object file. And i don't like to argue about this here – Quonux Jul 27 '13 at 23:50
Makefiles are indeed highly relevant. You may find that you need (at least) two different makefiles to compensate for the fact that you have different compilers.
It's hard to be specific about how you solve this, since it depends on how complex the project is. It may be easiest to write a script/batchfile, and just document "Use the command build.sh on Linux/Unix, and build.bat on Windows") - and then let the respective files deal with for example setting up the name of the compiler and flags, etc.
Or you can have an include into the makefile, which is determined by the architecture. Or different makefiles.
If the project is REALLY simple, it may be just enough to provide a basic makefile - but it's unlikely, as a compile of x.cpp on Linux/MacOS makes an object file is called x.o, on windows the object file is called x.obj. Libraries have different names, dll's have differnet names, and on Linux/MacOS, the final executable has no extension (typically) so it's called "myprog", where the executable under windows is called "myprog.exe".
These sorts of differences mean that the makefile needs to be different.

- 126,704
- 14
- 140
- 227
-
Can you provide an example of a project (perhaps on Github) that implements this multi-makefile solution? – danielmhanover Jul 27 '13 at 23:29
-
Not of the top of my head. I know I've downloaded sources in the past that has a few different makefiles, so for example "makefile.unix" and "makefile.win32". Generally, that makefile then includes one common file that contains the main parts, after having set up a few basic configurations. – Mats Petersson Jul 27 '13 at 23:35
-
I guess I shouldn't have written an answer at all, since you haven't actually defined very well what your problem is - what you have tried, where you are struggling, etc. – Mats Petersson Jul 27 '13 at 23:38
-
No, your answer makes sense. This is my first time deploying a command line utility like this so I wasn't sure where to start. But it does seem makefiles or scripts/batchfiles are the way to go – danielmhanover Jul 27 '13 at 23:42
-
Is there any make packaged with Windows, or is batch the only option that works with a pristine windows installation? – danielmhanover Jul 27 '13 at 23:53
-
1Anyone having a compiler for windows will have either `nmake` (Microsoft's tools) or gmake (as part of MingW or Cygwin) [may be called `make` or `gnumake` too, but there should be one]. Of course, someone not having a compiler on their machine will not be able to use a "compile your own" utility. You may want to consider using a secondary "deliver ready-made .exe" for those who want to use your utility on windows, but don't want to download/install a compiler just to use it for one project. – Mats Petersson Jul 27 '13 at 23:57