Cross Platform Question

[fsrichardson]

I am working on a project that currently uses the GNU tool chain (autoconf, GCC, GNU make, etc). We have been able to support Mac OS X, Linux and Windows with the same build tools by using Cygwin and MinGW on Windows (Mac OS X and Linux don't present much of a problem here).

...

I wanted to see about swapping out GNU GCC for the Intel compiler. Clearly this is not a problem for Linux or Mac OS X, but it is certainly a challenge for Windows since the Windows Intel compiler attempts to be a dropin for MSVC.

...

Also, we have been looking in to using Eclipse CDT as an IDE that would work on all three environments giving us one platform for our Java and JNI C++ code. Unfortunately here we have a problem too since the Windows Intel compiler doesn't have Eclipse integration.

...

What do other people do for cross platform developement? Is there any cheap route that does not require porting code and build mechanics to the MSVC system?

...

Has anyone succeeded in using autoconf with the Intel compiler on Windows?

...

Would it be possible to do integrate the Intel compiler by hand into Eclipse?

...

Is the only realistic route an alternate build environment? This seems impossibly expensive for evaluation purposes, but out of curiosity which ones would you recommend?

...

Any comments and/or suggestions are most welcome,

...

Thanks,

...

-Fred

[Fred_Richardson]

I think I can answer my own question now.
...
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.

[SergeyKostrov]

Hi Fred,

Quoting Fred Richardson

...that I'm in a small minority of people who want a low cost cross platform solution...

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.

Best regards,
Sergey

[TimP]

This thread has continued with private posts.
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.

[SergeyKostrov]

>>I think bat files would be a problem for me. I would have to maintain them along side whatever build
>>system I use for Mac and Linux.

>>At some point I will look at boost.build The library has really been ported around so many of the issues
>>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.

Best regards,
Sergey

[fsrichardson]

Quoting TimP (Intel)

This thread has continued with private posts.
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.

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:

http://software.intel.com/en-us/articles/alias-method-for-using-intel-windows-compilers-under-cygwin-bash-shell/