Re: [Caml-list] OCaml script on windows (was Re: [ANN] React 1.0.0)

[Adrien Nader <adrien@notk.org>]

On Sun, Apr 13, 2014, Anil Madhavapeddy wrote:
> On 13 Apr 2014, at 10:21, Adrien Nader <adrien@notk.org> wrote:
> 
> > The addition of functionalities doesn't sound like a very good idea to
> > me however. With all the
> > these-build-systems-suck-I-ll-just-write-my-own-build-system that I've
> > seen (mostly with autotools), I don't believe this is a good idea. A
> > comprehensive build system is a full project on its own and takes time
> > to get ready.
> > 
> > An example is probably x264: some disdain for autotools and lots of
> > hubris. I think that several years ago their "configure" script was
> > around 200 lines; nowadays it's 1300 lines. And there's some Makefile
> > and some more other stuff. And it is heavily biased towards GNU and
> > Linux.
> > And zlib is another example. But this one is so ridiculous it isn't even
> > funny.
> 
> Daniel isn't constructing a new build system though -- he's using
> ocamlbuild to take care of that.  He's simply looking for an efficient
> *packaging* system to redistribute his code and take care of the metadata.

Yes, and while I am not in favor of that, I'm not criticizing either (if
I wanted to, I'd just re-read the mailing-list archives). My point was
that adding bits here and there to the current setup would result in
something which will do more than that. Know where to stop (otherwise
you end up replaying GNOME 2 to GNOME 3 :D ).

> And autotools really does represent the worst of the approaches to me,
> having spent years digging through hundreds of thousands of lines of
> generated shell scripts to figure out why some obscure libtool option
> isn't working on OpenBSD.  By generating the code and committing it,
> chances are that it'll be very hard to regenerate in the future.  We've
> already seen hints of this in OASIS with the minor incompatibility in
> its generated code with OCaml 4.0+, which took us about 4 months of
> bulk builds and cajoling upstream maintainers to get rid of the last
> vestiges of.  Not really OASIS's fault (bugs happen), but the basic
> architecture of "follow the autotools philosophy" causes this.

I've had the absolutely opposite experience with builds for Windows. Of
course some things in autotools aren't perfect and m4sh was probably the
wrong solution but current autotools are fairly easy to write and work
well for me (which usually includes platforms with gnu-isms but also
cross-compilation to Windows).

I notice two main issues with autotools:
- bad API usage
- additional hooks in the build system


About API usage: a few days or weeks ago, I was working on a package for
something autotools-based. In order to check for the availability of a
feature, it ends up building and running an executable. Of course this
fails for cross-compilation but the documentation for autoconf's
AC_RUN_IFELSE is clear :
  Macro: AC_RUN_IFELSE (input, [action-if-true], [action-if-false],
  [action-if-cross-compiling = ‘AC_MSG_FAILURE’])

I don't think the framework can be blamed for that.


As for additional hooks, I have too many bad examples to count them.
Starting with curl's and c-ares' way to find the prototype to select()
and friends: they test the combination of all possible argument types
(yes, all the 1440 ones; and there's an invocation of cc for each one).

And libpng which has hooks at installation to rename libraries (libpng's
handling of shared library versioning is a spectacular failure and has
been so for over a decade).

Or fontconfig which required a --with-arch argument to configure;
apparently it couldn't derive it from --host even though it was the
first element of the architecture triplet (this is fixed now).

And GTK+-2 which tries to run the command "no" when cross-compiling
because it did "checking for gtk-update-icon-cache... no" and then ran
the "command".

Absolutely all of these (and more) are project-specific additions and
it's these additions which cause the most issues, not the regular
autotools part. Maybe they should rename the ability to insert arbitrary
shell scripts into the build process into the ability to add some crap
to make sure software doesn't build well.

With that said, I think that some version of autotools several years ago
had a gnu-ism in the shell scripts and it's a similar issue to the
migration to 4.00 with Oasis.
This definitely happens but it should always be possible to regenerate
the build system; when it isn't, it's a failure of upstream. If you're
not supposed to forget the .ml files, why would it be OK to forget the
other ones?

And on that last point, generated files should *NOT* be committed. They
are to be generated and put into tarballs but not source control system.
I've criticized my share of people about that through IRC.

I really don't think it's the tools which are to be criticized nowadays;
it's the people.

I didn't mean to start a discussion on autotools with my example. It was
just an example of "*I* will do better" [ most probably by a
specific contributor to x264 who has that attitude towards everything ]
and clearly failing to do so when looking at it a few years later. It
was a word of caution with an example.
My experience is simply so different from what you describe that I had
to explain what I've witnessed.

> I do like the fact that I can glance at Daniel's repositories and
> understand what's going on in minutes rather than days...

Which was my point: if you are making something new because you find the
existing solutions too complex and complicated, make sure you don't turn
your cute-and-simple solution into something gigantic.

Clearly, autotools is complex. Which is not a big surprise considering
its constraints. And I wouldn't like debugging it but so far I haven't
had to! Now, with a new and unproven system, I'll likely have to(*) and
I don't really mind it as long as it's small but then, again, I'm
worried that it grows and stops being that short piece of code that can
be read and debugged quickly.
(*) mostly because I'll be doing cross-compilation to Windows and it's
mostly unproven


-- 
Adrien Nader