I have two different options in gcc.
In linux is one in Mac other
How check in makefile what system current is?
Windows, Linux, or OSX
You can use built in shell commands such as uname (on Unix systems) and parse the output. There's no built in functionality for it.
If you're doing this with the intention of distributing software, then rather than tweak Makefiles internally (there is no good solution to this; I wouldn't even try), you should investigate a build system which allows users to configure the build dynamically.
The most common mechanism for that is autoconf. Autoconf is a little tricky to get started with – there's a non-trivial learning curve, but it's in reality somewhat simpler than it looks at first – but it has the advantage that use of autoconf is very widespread. If people are building a bit of software from source, they're rarely surprised to see a configure script, at which point their fingers automatically tap out ./configure; make; make install.
The Wikipedia page on autoconf actually makes it look rather harder than it is, because the diagram displays the full-blown autoconf+automake+autoheader+aclocal ecosystem (what, they missed out libtool?!). That page also rather goes to town on its ‘Criticism’ of autoconf. While none of the points it makes are actually false, their importance is rather overstated.
Simple add this in Makefile:
ifeq ($(UNAME_S),Linux)
OPCJE = -Wall -Wno-unused-const-variable
else
OPCJE = -Wall
endif
Related
As it is stated on the FT Jam page at freetype.org:
Jam is a small open-source build tool that can be used as a replacement for Make. Even though Jam is a lot simpler to use than Make, it is far more powerful and easy to master. It already works on a large variety of platforms (Unix, Windows, OS/2, VMS, MacOS, BeOS, etc.), it is trivial to port, and its design is sufficiently clear to allow any average programmer to extend it with advanced features at will.
Are there any ways to substitute make for jam to make autoconf-based projects in MinGW / MSYS to build faster?
No. Autoconf relies on a Unix shell and associated utilities. It might be hacked to generate jam files, but the configure step is autotools. If you just have a plain makefile, you might as well just use mingw32-make and ditch autotools completely if possible.
For a university course I have to write a http server which is supposed to run on both Linux and Windows.
I have got a humble Linux machine which I don't think can handle any kind of heavy virtual environment, neither I'm willing to go through the hassle of installing it.
This is the first project of mine complex enough (I estimate ~1.5 months to develop) to require an environment sufficiently comfortable to alternate rapidly between short coding and testing sessions (the latter on both platforms, of course).
So, I was wondering what could be the best set up for this situation. I think testing it on Wine would be ok (it is not a real-world thing, after all), and I installed MinGW for the Windows-targeting part.
Basically, a simple well-written makefile could solve my problem... It should build both the Linux and Windows binaries and place them in the respective folders (the Windows one in the Wine sub-tree) and I'm all done! But I feel very inexperienced in this thing and I really don't know where to start. Maybe the make manual, ahah!:)
Thoughts, suggestions, anything I didn't think/know!
Thank you!
(PS. I'm planning to use emacs as editor, or maybe learn vim. Unless eclipse provide some kind of skynet-like plugin that entirely solve this problem...:)
You're on the right track. It's not that complicated, really, thanks to MinGW. You basically need two things:
The code has to be portable across the OSes. MinGW has some POSIX support, but you'll probably need to either use Cygwin in order to be able to use the POSIX interface or have your own compatibility layer for interfacing with the OS. I'd probably go for Cygwin as then you can code only against POSIX and won't have to test and debug your compatibility layer. Also, make sure you won't use any external libraries that are OS specific. Non-portable code often results in a compile error, but make sure you test the application thoroughly anyway.
The toolchains for targeting Linux and Windows. You already have them, you just need to use them correctly. Normally you'd use a variable like $(CROSS_COMPILE) as a prefix when calling the toolchain during cross compilation. So when compiling for Linux, you call gcc, ld, etc. (having the CROSS_COMPILE variable empty), and when compiling for Windows you call e.g. i486-mingw32-gcc, i486-mingw32-ld etc., i.e. CROSS_COMPILE=i486-mingw32-. Or just just define CC, LD etc. depending on the target.
I wrote a small game on Linux and made it run on Windows as well. If you browse the code, you can see the code has next to no #ifdef jungle (basically just some extra debugging features enabled for Linux), and the Makefile is simple as well, with no complicated handling for cross-compilation, just the possibility to override CC etc. like it should be. As lots of important open source software is written this way (especially software that's used by the desktop and embedded devices), you should also be able to find lots of other examples on how to set up the build environment correctly.
As for testing the application on Windows, I think the best option is if you can find a real Windows machine somehow. If you do everything correctly, it should run the same as on Linux and you won't need to continuously test your application on both OSes. If testing on a Windows machine is not possible, a VM would be the next best choice, though it would probably be more difficult to set it up. Wine is a good backup plan, but I don't think you can be sure your application works well on Windows if you only tested it on Wine.
Hoping for a bit of insight here. I have source code for one of our projects, with no documentation on how to compile, and all people who wrote it having left :) We have an issue in it and lucky moi has been tasked to investigate.
Currently I'm trying to build on AIX, the makefile keeps on complaining with either
make: 1254-055 Dependency line needs colon or double colon operator.
or
make: 1254-057 Shell command needs a leading tab.
The CPP options seem to be xlc options, and the software has been compiled many times before. The makefile contains control characters from windows in it and does have tabs against some of the entries but not all the shell commands.
Any thoughts on what could be the issue running make on the code? I haven't installed GNU make as of yet, could this solve the issues?
Classic SysV make is much more picky about formatting than gnumake is, never mind the feature set is much more restricted. I don't even bother writing "classic" compatible Makefiles anymore - too painful.
Even though we use the native compilers (xlc) on AIX, we still use gmake as our dependency/build tool.
I recommend installing a managed copy of gmake, downloadable from a couple sources:
Direct from IBM thru the AIX/Linux toolbox.
As an RPM from here.
From Bull here.
As lpp packages from pware here.
Good luck!
I think you might need to use gmake even on AIX. The original make may not be working as expected. The Windows control character may or may not matter (usually does not), but can be edited out on vi.
With C++ sources, in my company :
On AIX, we use make (and xlC_r compiler).
On AS400, we use gmake (and ixlc compiler). Because make exists, but is PASE only.
gmake was certainly found on some old website... there are many other GNU programs on our iSeries. I haven't found any trace of it beside the PGM.
I'm lately feeling the need to learn a build tool. I'm looking through StackOverflow for recommendations and Gnu Make gets barely mentioned. Instead I see Ant, Maven, CMake, Scon and many others. However, when I look at the little "rogue sources" (as in not-in-the-repo) that I sometimes have to compile, they all require the make && make install steps.
Is learning Make a worse investment of my time than learning another tool?
If so why is Make still so popular?
Make is the standard build tool for everything C/C++. Many others have stepped to the plate, but even when they were useful and successful, they never achieved the ubiquity of make.
Make is installed on virtually every Unix-like machine out there. No matter if you're working with AIX, Solaris, Irix, BSD, or Linux, if there's a compiler installed, there's also make.
Some of the "replacements" (like Automake, CMake) even create Makefiles, which are in turn executed by make.
I would definitely recommend becoming familiar with make. If handled by someone who took the time to learn about make, it is a powerful tool, which can be used in a number of ways not even necessarily related to software development.
Even if you end up using a different build tool in the end, you will be able to "recycle" the lessons learned with make, as the underlying concepts are quite similar. And the sheer number of make-built projects means that there will always be the chance that you have to figure out an existing Makefile.
One thing, though. Get it right from the beginning.
I think the reason you don't see (GNU) make mentioned is that it's often the default; if you have a GNU toolchain, you will have make already. Thus, most people that start talking about build tools, talk about something else.
In my experience, make is fine, but it can be kind of tricky to get it to do exactly what you want to. It's maybe slightly arcane, but it's proven and works.
Make is popular because it's used (mainly) for C/C++ sources in Linux/*nix projects, and is far older than any of the other tools you've mentioned, thus it has stood the test of time and is mature. Kinda like tar.
To be honest with you, I only know make. Those other tools above may be better, but so many projects just use a basic Makefile that you're best off knowing at least a little bit of it. Not only for your own projects at work but most of the open-source ones you find on the net.
It really depends how much you will use it.
If yoy work a lot with C/C++ make projects, then yes, I would recommend learning more about it as a large make file has a steeper learning curve than other build tools you mention.
If you don't work with make, or work in other languages such as C#, Java or PHP then you'd be better off learning build tools relevant to those languages.
Like all tools, if you use it at all, you should put some time
into becoming reasonably adept at it. Also, some tools (like CMake, for example) generate makefiles and you may one day need to mess with those generated files.
GNU make has an excellent manual - it's certainly worth spendin an hour or two reading it.
Make is the de-facto standard on Linux systems for example. It is a very complex tool, and also a very powerful tool.
It is well suited to learn if you are developing C or C++, particularly if targeting Linux/*nix.
One of the features of make, is that you can set up dependencies for when to rebuild a file. E.g. each c or c++ file is build into an .obj file, and in the end, all .obj files are linked to an executable. But maybe the executable is a statically linked library, that is linked into another executable with other .obj files.
Make can make sure that you compilation time is as short as possible, because you can define that a c file should only be compiled if it, or any dependent header files, are newer that the .obj file. So any compilation or linking step is only executed if the current source files for the step is newer that the target file.
If you are developing in for example C#, you don't need this kind of dependency checking because all .cs files are compiled at once into a single executable.
So the conclusion is that you should use a build tool that is well suited for your choice of programming language.
Even if you end up preferring another build tool (personally I'm fond of VS... I know...) knowing make will probably prove more useful.
Make has many applications and whilst it is not always ideal for a single task, when dealing with new technologies it is stalwart and flexible.
I guess where you work is probably different, but I know that everywhere I've worked I would have been a far less valuable employee if I hadn't at least learned how to read Makefiles. Even in all Windows-VisualStudio environments, it comes up every now and then.
For instance, we just got a job that involves porting a bunch of old CX/UX code to Windows. The old code was built with makefiles. There's no way to understand their old system without knowing how to read those old makefiles.
Is there any difference between makefile in Windows and Linux?
If I know how to use it in Linux, is it necessary to learn
something new when in Windows system?
The fine folks over at GnuWin32 have Gnu make built for Windows as a native binary. It works well, but does have a few minor quirks due to a well-intentioned hack that tries to equate a target named foo with the file foo.exe. The GnuWin32 package does include a nice PDF of the manual, IIRC.
I use it on XP alongside GCC from the MinGW project, as well as with several different embedded systems cross compiler toolchains. MinGW also provides a native build of Gnu Make.
We do use Cygwin for a couple of projects, in particular one where the system-on-a-chip vendor provided a complete, working toolchain and build environment hosted in Cygwin. Moving it to a native Windows shaped build would be prohibitively expensive, and would make it harder to accept updates from the vendor.
If you want to use mostly native Windows tools, but need to start by running configure on an existing source kit, then take a look at MSYS. This started as a fork of Cygwin by the MinGW developers, and it intends to provide a minimal set of unix-like tools with a bash shell so that configure can be used on Windows. It isn't as complete as Cygwin, but it is a lot lighter weight.
You will find that the manual for Gnu Make is mostly true. However, you have to keep in mind that the content of a Makefile is not written in a single language. The stuff that defines variables and lays out the dependancy tree is one language. Each line of an action is a miniature shell script that is in the language of the default shell (which might be CMD.EXE rather than /bin/sh on Windows), and each command has options and arguments.
If you are comfortable with your *nix build environment, then Cygwin might be the path of least pain. But MSYS is often sufficient, and there is something to be said for adopting the native tools of the target platform so that you have a sense of how your users see Windows, in which case MinGW and GnuWin32 are handy resources to know about.
In addition to what iftrue note that Microsoft has a Makefile based build tool called nmake with some changes in syntax/semantics from the traditional *nix based make tool. This page lists some of the differences.
Well, if you download "cygwin", you can run the "make" tool directly on windows, but you may want to look into a true cross-platform build tool such as "cmake". It's like make, but it's a bit more spiffy and is inherently cross-platform.