Re: [Caml-list] One build system to rule them all?

[Adrien Nader <adrien@notk.org>]

On Wed, Sep 10, 2014, Yotam Barnoy wrote:
> Here's part of my motivation for starting this discussion now: I recently
> experienced a hard-drive failure and had to switch to my backup windows
> laptop. I was dismayed that opam is still not available for Windows, and
> while wodi is available, it's not nearly as well developed, and apparently
> requires many hacks for different packages.
> 
> It seems to me that these hacks are some of the things that make platform
> compatibility hard for opam. Each build system has different requirements
> and methods of compilation, and making this approach cross-platform
> compatible is difficult. Ideally, a build system will abstract away the
> things that are not inter-platform compatible. This is why I don't like
> people using makefiles. Makefiles are not available natively on Windows,
> and they often contain other bits of shell code that isn't available on all
> POSIX platforms, let alone on Windows. Not to mention the fact that
> makefiles have a very tricky and sensitive syntax.

You're taking the wrong approach IMHO. The issue is not with the build
systems (usually) but with the build environements and how you're using
them.

On Windows you have three choices to build from. Chose one. Stick to it.
Don't mix.

1- Cygwin or MSYS/MSYS2 (MSYS is a fork of Cygwin; MSYS2 is a fork of
newer Cygwin).
They are POSIXish (Cygwin) or POSIX-like-but-actually-doing-dirtytricks
(MSYS*). They can run both regular Windows apps and specific cygwin/msys
apps too.
Consider that when from Cygwin, you will be doing a special
cases of cross-compilation which allows you to run what you've built
(but you will probably have to post-process the output of what you run
if it contains paths).
On MSYS*, you'll try to mix both that not-really-posix universe with
windows and it should work most of the time. If you look deeper at how
it's mixing things, you will probably feel like never using it ever
again.

2- Visual Studio.
First you need to click on the "I accept this EULA" tickbox to sell your
soul to Microsoft.
Then you will discover a world of ad-hoc solutions, collection of blobs
and random binaries, build cargo cult and "I'm keeping this installation
since it builds what I need and it's too risky to change it; I know it's
running Windows 98 and Visual Studio 6 but it works!".
This beast is also the reason CMake is engineered the fail at finding
dependencies except when you give it their full path along with every
possible bit of information it might need during build since it won't
find anything (handy, hey?).
[ that's really the design idea behind cmake's configuration
"discovery": you list paths and libs and it tries them until it finds
something which passes the insufficient match tests given; you're
supposed to avoid pkg-config or at least make it a secondary citizen,
which means it's broken and every lib detection script has to reinvent
pkg-config usage in a broken way using the horrible cmake macro language
]

3- Other IDEs.
Some tend to use a make. A native one which spawns cmd.exe. I guess they
write Makefiles which contain very simple commands. It seems they work
fine. Makefiles are generated from some IDE-specific code. They share
some of the bad things MSVC but at least they're not building using a
dump of blobs and they don't change their project description
fileformats with each version.

Pick your broken system. Send love letters to Microsoft.

As far as I'm concerned, I'm cross-compiling from Linux. Or sometimes
from Cygwin. And when I really need to, from MSYS. In other words, I
solve the issue by avoiding Windows as much as possible, even when on
Windows.

Pick one. Understand it. Don't cross the streams. Eat five vegetables
and fruits per day. Alcohol and other drugs are not the answer (violence
is).

-- 
Adrien Nader