[Developers] ADMB, GCC, and the Windows build process

[Arni Magnusson]

Here are some thoughts about ADMB and GCC for Windows in the long term, 
not necessarily related to the ongoing release. Essentially, the core team 
needs to decide between two options:

1. To build ADMB with MinGW from scratch, the user only needs a GCC 
compiler, for example the c:/gnu/gcc472 that comes with ADMB-IDE. This is 
pretty much how things are now.

2. To build ADMB with MinGW from scratch, the user needs the MSYS Linux 
emulator, a system that provides a Bash shell and behaves like Linux. This 
is how things were at some point.

As far as I can tell, the pros and cons of Option 1 (MSYS) are the 
following.


Pros:

We can then use the same makefile tree for Windows and Linux. This should 
result in a makefile tree that is easier to understand and maintain.


Cons:

MSYS intertwines the GCC compiler (170 MB) with lots of other stuff 
(another 170 for a total of 340 MB), like Perl and its own package 
manager. So it would probably not be a good idea to include the entire 
MSYS system inside the ADMB-IDE installer, right?

So if we take Option 2, users who already have c:/gnu/gcc472 (created by 
ADMB-IDE) would need to install MSYS as well, just to build ADMB, even 
though they already have g++ on their machine. They would now have (at 
least) 2 installed C++ compilers, maybe 2 installed Perl interpreters, 
etc. Some potential for confusion and software conflicts.

One option would be to offer ADMB-IDE-mini, which would include Emacs but 
not GCC, intended for users who have MSYS installed. With 64 bits and 
zips, this would mean a lot of confusing IDE distros.

Another option would be to offer only ADMB-IDE-mini. Then ADMB-IDE would 
no longer be plug-and-play, but rather assume that GCC is already 
installed and configured. This would be a big step backwards for ADMB 
beginners who have little experience with compilers or modifying their 
PATH. It's hard to enough to get an introductory workshop up and running 
as it is.


Conclusion:

These are big pros and cons. Option 1 is nice for users (ADMB can be built 
with a minimal g++ compiler, no need for anything else), while Option 2 is 
nice for the core team (simpler makefiles).

One possible solution would be to embrace MSYS and include it inside the 
ADMB-IDE installer, along with Perl, the MSYS package manager, and the 
kitchen sink. Disk space is cheap - and maybe it's safe to remove 
everything from c:/mingw/var/cache before building the ADMB-IDE installer?

The current ADMB-IDE installer (admb-ide-101-win32.exe) is "only" 74 MB, 
so I'm by no means convinced that including MSYS inside it is the way to 
go. Maybe it's best to keep the installer minimal, and just let the 
fraction of users who want to build ADMB from scratch have both 
c:/gnu/gcc472 and c:/mingw on their computer. Or stay with Option 1 and 
just make small improvements to the current makefiles to provide Option 2 
as well.


Let's continue to explore this, after the current version release is 
finished.


Arni



On Mon, 22 Apr 2013, Chris Grandin wrote:

> Hi all,
>
> If you download MinGW and check off all the check boxes on the install 
> (include MSYS and developer tools), and include 
> c:\MinGW\bin;c:\MinGW\msys\1.0\bin in your PATH, then you can just open 
> the MinGW shell and run the linux compile commands as written in the 
> README file to build the source.  This is how I did it from the start 
> and it worked great.  This method also avoids having to maintain 
> utilities/minGW parts of the project (MinGW parts of the README could 
> just say "Open a MinGW MSYS shell and follow linux commands").  No 
> external utilities that we need to keep track of are required when you 
> do it this way.
>
> I have reverted to revision 767, before all the changes happened because 
> minGW will not compile the source correctly now. It will compile and run 
> the samples but will not link to the contrib libaries properly.  Note 
> there are no tests for contrib linking so it appears A-OK on the testing 
> machines.
>
> I'd be happy to write up this method up on the webpage if we can revert 
> to a working copy!
>
> Chris
>
>
>
> On Mon, 22 Apr 2013, Johnoel Ancheta wrote:
>
>> Hi Arni,
>>
>> We should press on and get this release out.  I'm going to need some 
>> help with documentation.
>>
>> Johnoel
>