For working on the same code in multiple environments (Windows/Mac/Linux) with the Intel compiler, you really need to look for a build system. I've heard of two systems mentioned so far and I believe there are more with their pros and cons: CMAKE and bjam (or boost::build). CMAKE is supposed to be a build meta system that can do anything from creating project files for Eclipse, creating Make files for a GCC or creating whatever files MSVC uses all from the same source. I've also heard that it's very hard to maintain. BJam is pretty low level, but it is used to build Boost on a variety of different platforms with a variety of different compilers so it might not be too bad.
So there really isn't a good option for me. It's too bad that the intel compiler is not a drop in for MINGW. An yet it is a drop in for GCC on Linux and almost the same compiler on MacOS? I guess I don't fully understand this except that I'm in a small minority of people who want a low cost cross platform solution.
My best option seems to be to use Eclipse on all three platforms with MinGW on Windows.
Quoting Fred Richardson
I decided to follow an extremely simple pathwhen building source codes. The path isbased on bat files
instead of make files.
For example, this is how abat file for compilationof all test caseslooks like for a MinGW C/C++ compiler
and Win32 platform and Release configuration:
@echo ***Compiling with MinGW v3.4.2 ***
@echo ***Configuration - Desktop - _WIN32_MGW - RELEASE ***
@g++.exe -B ../../AppsSca -DNDEBUG -o Release\MgwTestApp.exe MgwTestApp.cpp
A project is organized insuch away that compilation starts from 'MgwTestApp' and all the rest will be
"attached" through a well designed set of configuration cfg files,header files, etc. That approach
guarantees integrity of all subsystems because they arealways re-compiled. Since modern computers and
C/C++ compilers are veryfast this is not a problem at all.
More in line with the original question, I'll add:
gnu make (versions such as those used with mingw or cygwin, for instance) is suitable to run on Windows to maintain consistency with linux or other posix-like usage. .SUFFIXES and make rules have to be modified to account for Microsoft-style usage. A few of us prefer such a method rather than wholesale conversion to non-posix make utilities. If the makefile depends on a specific linux shell, such as bash, it may be more feasible to run the build under a Windows port of the same shell.
It is possible to adopt either .o or .obj file naming. Microsoft link works with either (lots of warnings with .o).
In the X64 mode, it's likely you will need Microsoft tools such as lib rather than 32-bit ports of gnu ar, for example.
In general, autoconf tools set up for linux may not work with Visual Studio plug-in compilers. They work to some extent as, for example, in mingw compiler configuration.
>>system I use for Mac and Linux.
>>may have been dealt with (for my purpose anyway).
My initialobjectives were very simple. That is, a maintenance free build system. Since several platforms and
many C/C++ compilersare supported already I wouldn't consider some replacement in a form of a
makefile even if it could be better. The reason is simple:an extra time will beneeded to make that "useful"
upgrade. As I mentioned some time ago when a build is working, for example on a 32-bit Windows platform,
the "bat-system" isinvoked from the Visual Studio 2005 andallows me easily verify the source codes
compatibility because four C/C++ compilers will be used one after another. I agree, that it could be also
achieved with a makefile.
My apologies - I am new to the forum and had no understanding of how private worked (I thought a response to a private post would automatically be private for example).
I like Make, but it does require a lot of work to maintain. Autoconf has been extremely useful for us for working on three platforms: Linux/GCC, MacOS/?CC, Win7-64/MinGW but as you said it can't seem to handle the microsoft (or Intel) tool chain.
As there is not drop-in replacement compiler for what we're doing, I will likely stick with MinGW under Windows. I could compile a few DLL's selectively using the Intel compiler.
I found the following web page very helpful (not sure if I already posted it). Just in case anyone else is searching for an answer to the same question I had: