From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 4474F7F720 for ; Sun, 13 Apr 2014 13:17:53 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of adrien@notk.org) identity=pra; client-ip=91.121.71.147; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="adrien@notk.org"; x-sender="adrien@notk.org"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of adrien@notk.org designates 91.121.71.147 as permitted sender) identity=mailfrom; client-ip=91.121.71.147; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="adrien@notk.org"; x-sender="adrien@notk.org"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@nautica.notk.org) identity=helo; client-ip=91.121.71.147; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="adrien@notk.org"; x-sender="postmaster@nautica.notk.org"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoFAA1xSlNbeUeT/2dsb2JhbABZgwaDUFLAHYEZFnSCJQEBAQMBIw8BOwsFCwsSBgICBRMOAgIPBRgdARMTG4dZDKgQohgXgSmIHYUoB4JvNYEUBJR0g2wBkkODMzs X-IPAS-Result: AgoFAA1xSlNbeUeT/2dsb2JhbABZgwaDUFLAHYEZFnSCJQEBAQMBIw8BOwsFCwsSBgICBRMOAgIPBRgdARMTG4dZDKgQohgXgSmIHYUoB4JvNYEUBJR0g2wBkkODMzs X-IronPort-AV: E=Sophos;i="4.97,851,1389740400"; d="scan'208";a="67964757" Received: from nautica.notk.org ([91.121.71.147]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/ADH-AES256-SHA; 13 Apr 2014 13:17:52 +0200 Received: by nautica.notk.org (Postfix, from userid 1003) id B46C4C01F; Sun, 13 Apr 2014 13:17:51 +0200 (CEST) Date: Sun, 13 Apr 2014 13:17:51 +0200 From: Adrien Nader To: Anil Madhavapeddy Cc: Daniel =?utf-8?Q?B=C3=BCnzli?= , "caml-list@inria.fr" Message-ID: <20140413111751.GA15558@notk.org> References: <9636C678CAA541CCB505CE8771722A68@erratique.ch> <063FC564F6B44EA5AB1CF1D5589996D0@erratique.ch> <20140412073949.GA31995@notk.org> <20140412074401.GA803@notk.org> <20140412114145.GA18285@notk.org> <74C2E1F54AA349E6899E909804979B72@erratique.ch> <20140413092144.GA1838@notk.org> <06FC9D12-A9BB-41C7-8C3E-EADBA1157F89@recoil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <06FC9D12-A9BB-41C7-8C3E-EADBA1157F89@recoil.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [Caml-list] OCaml script on windows (was Re: [ANN] React 1.0.0) On Sun, Apr 13, 2014, Anil Madhavapeddy wrote: > On 13 Apr 2014, at 10:21, Adrien Nader 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