[Caml-list] [ANN] React 1.0.0

[Caml-list] [ANN] React 1.0.0

[Daniel Bünzli]

Hello, 

I'd like to announce the release of React 1.0.0 which should be
available shortly in opam. 

React provides declarative events and signals for functional reactive
programming (FRP).

Home page: http://erratique.ch/software/react
API Documentation: http://erratique.ch/software/react/doc/React

This is an incompatible release. Here are the main changes:

1. Exposes update steps (formerly called update cycles) in the
   API. This allows to perform transaction-like, semantically
   simultaneous, *primitive* signal updates and event occurences. It
   can make the reactive engine both more convenient and efficient for
   certain use cases.
   http://erratique.ch/software/react/doc/React.Step

2. To avoid leaks when weak arrays are not (i.e. JavaScript), some
   form of manual memory management can now be performed by using the
   new `strong` optional parameter of {S,E}.stop on the leaves of your
   reactive system.
   http://erratique.ch/software/react/doc/React#strongstop
  
3. S.switch no longer requires a bootstrapping argument. As a result
   S.bind is now trivially definable and is provided by the
   module. Consult the release notes for an equation to migrate your
   code.

Other details are in the release notes:

  https://github.com/dbuenzli/react/blob/master/CHANGES.md

Best,

Daniel

Re: [Caml-list] [ANN] React 1.0.0

[Daniel Bünzli]

Le mercredi, 2 avril 2014 à 18:01, Daniel Bünzli a écrit :
> As a result S.bind is now trivially definable

In fact it's so trivial that I managed to get it wrong (signals can't be compared structurally, it may raise). I'll do a bug fix release in a few days but meanwhile you can pin the github repo:

opam pin react https://github.com/dbuenzli/react.git

Best,

Daniel

Re: [Caml-list] [ANN] React 1.0.0

[Markus Weißmann]

Hi Daniel,

while at it, could you please provide a non-opam style installation 
routine? (Oasis, Makefile, ..)
I maintainthe package of React for macports and having yet another type 
of installation routine really makes my life complicated; I haven't 
updated the package to React 1.0 yet, as I haven't found the time to 
"re-engineer" the opam stuff -- including the question if DESTDIR is 
supported that way.
Perhaps the Debian-ocaml maintainers can help me out on how they cope 
with "opam-only" libraries.

Regards
Markus

On 2014-04-08 03:04, Daniel Bünzli wrote:
> Le mercredi, 2 avril 2014 à 18:01, Daniel Bünzli a écrit :
>> As a result S.bind is now trivially definable
>
> In fact it's so trivial that I managed to get it wrong (signals can't
> be compared structurally, it may raise). I'll do a bug fix release in
> a few days but meanwhile you can pin the github repo:
>
> opam pin react https://github.com/dbuenzli/react.git
>
> Best,
>
> Daniel

Mit freundlichen Grüßen

-Markus Weißmann

-- 
Markus Weißmann, M.Sc.
Technische Universität München
Institut für Informatik
Boltzmannstr. 3
D-85748 Garching
Germany
http://wwwknoll.in.tum.de/

Re: [Caml-list] [ANN] React 1.0.0

[Daniel Bünzli]

Le vendredi, 11 avril 2014 à 17:12, Markus Weißmann a écrit :
> while at it, could you please provide a non-opam style installation
> routine? (Oasis, Makefile, ..)

Sorry but the answer is no. 1) I don't have the time for that 2) oasis is a broken idea that gets in the way 3) I don't want to maintain more than one build system 4) I don't want to have to implement an install procedure in each of my packages.  

For react the build system is very simple, from the root directory of the distribution you have to invoke a single shell script as follow:

./pkg/build $HAS_NATIVE  

Where HAS_NATIVE should be "true" if you have ocamlopt and "false" if you don't. This will build the artefacts using ocamlbuild and generate a react.install file at the toplevel directory of the distribution. You can then either process this file yourself or more recommended directly use the opam-installer tool distributed with opam to process this file and install the files at a given $PREFIX.

Note that this procedure is the same for the dozen of packages I distribute except there may be more booleans to pass to the `build` script to specify optional dependencies. See e.g. Vg's pkg/build usage: https://github.com/dbuenzli/vg/blob/master/pkg/build#L3

Feel free to ask me any question if you run into problems.

Best,

Daniel

Re: [Caml-list] [ANN] React 1.0.0

[Anil Madhavapeddy]

On 11 Apr 2014, at 16:58, Daniel Bünzli <daniel.buenzli@erratique.ch> wrote:

> For react the build system is very simple, from the root directory of the distribution you have to invoke a single shell script as follow:
> 
> ./pkg/build $HAS_NATIVE  
> 
> Where HAS_NATIVE should be "true" if you have ocamlopt and "false" if you don't. This will build the artefacts using ocamlbuild and generate a react.install file at the toplevel directory of the distribution. You can then either process this file yourself or more recommended directly use the opam-installer tool distributed with opam to process this file and install the files at a given $PREFIX.

Using opam-installer seems fairly straightforward, as it has a -prefix option which should permit installing into a fakeroot or other custom DESTDIR.

The only request from a packaging perspective I have from your scripts is to also have a $HAS_NATIVE_DYNLINK, as there are some architectures for which we have native code support (like sparc) but no native dynlink support yet.

cheers,
Anil

Re: [Caml-list] [ANN] React 1.0.0

[Daniel Bünzli]

Le vendredi, 11 avril 2014 à 18:05, Anil Madhavapeddy a écrit :

> The only request from a packaging perspective I have from your scripts is to also have a $HAS_NATIVE_DYNLINK, as there are some architectures for which we have native code support (like sparc) but no native dynlink support yet.

Ok thanks for the info. Will implement that once I get some free time in my hands.  

Just to confirm having $HAS_NATIVE_DYNLINK to false should just prevent the build of the .cmxs artefacts right ?  

And according the dev manual (§ 4.2) there's no variable in opam for that, I made a request here:

https://github.com/ocaml/opam/issues/1324

Best,

Daniel

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

[Daniel Bünzli]

Le vendredi, 11 avril 2014 à 18:32, Daniel Bünzli a écrit :

> Ok thanks for the info. Will implement that once I get some free time in my hands.

I may also take that as an opportunity to rewrite these *trivial* shell scripts in ocaml for improving windows compatibility. Here are a few questions to the list:

1) What should I use for #!,  /usr/bin/env ocaml  ? And what will windows do with that ?  

2) The only OS related things I do is write the .install file and invoke ocamlbuild once with all the targets that need to be build. Is Sys.command enough for that ? and is the invocation syntax identical ?  

Thanks for any insights/pointers,  

Daniel

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

[David Allsopp]

Daniel Bünzli wrote:
> Le vendredi, 11 avril 2014 à 18:32, Daniel Bünzli a écrit :
> 
> > Ok thanks for the info. Will implement that once I get some free time in
> my hands.
> 
> I may also take that as an opportunity to rewrite these *trivial* shell
> scripts in ocaml for improving windows compatibility. Here are a few
> questions to the list:
> 
> 1) What should I use for #!,  /usr/bin/env ocaml  ? And what will windows
> do with that ?

Windows can't do anything with that. However, most people compiling OCaml packages on Windows expect to use bash (either from Cygwin or MSYS), where the scripts would run as on Unix. Are you sure that Windows compatibility is already a problem?

> 2) The only OS related things I do is write the .install file and invoke
> ocamlbuild once with all the targets that need to be build. Is Sys.command
> enough for that ? and is the invocation syntax identical ?

As long as you don't do anything exotic with command line parameters (quoting can be very weird for the Windows command processor, cmd, which is what Sys.command uses) then yes, Sys.command will be fine, and the same as on Unix.

In passing, it does have to be said that getting Windows support automatically from your build system is something that OASIS does...


David

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

[Daniel Bünzli]

Le samedi, 12 avril 2014 à 00:33, David Allsopp a écrit :

> Windows can't do anything with that. However, most people compiling OCaml packages on Windows expect to use bash (either from Cygwin or MSYS), where the scripts would run as on Unix. Are you sure that Windows compatibility is already a problem?

No, I just thought that you wouldn't get a shell on windows. So maybe you are right, nothing needs to be done, reports welcome.

That being said with an ocaml rewrite I'd abstract the thing a little bit more to make it more DRY (I deliberately prevented myself of doing that in sh: possible but guaranteed to become un-rereadable once you figured out the magic invocations)
  
> s long as you don't do anything exotic with command line parameters (quoting can be very weird for the Windows command processor, cmd, which is what Sys.command uses) then yes, Sys.command will be fine, and the same as on Unix.

Ok and ocamlbuild is ocamlbuild not ocamlbuild.exe ?

> In passing, it does have to be said that getting Windows support automatically from your build system is something that OASIS does...
At an unacceptable time cost, level of complexity and insulation from your build system… oasis maybe fine if you distribute a single package and have time to loose fighting with the system. It's not when you formally release a dozen of packages (and plan to release more).  

At the risk of repeating myself I need simple, reliable, efficient release and packaging workflows: right now if I need to perform a 5 min administrative task on each of my released packages that's already an hour of my time that is gone and I hate admin tasks. So it turns out that in *my* case, I'm very well served by opam .install files, ocamlbuild and a 100 loc, trivial, shell script [1] that I hope I'll be able to kill if we once get a good build system that has decent packaging support and handles .install file generation for me.

Best,

Daniel

[1] https://github.com/dbuenzli/pkgopkg/blob/master/pkg/pkg-builder

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

[Daniel Bünzli]

Le samedi, 12 avril 2014 à 01:38, Daniel Bünzli a écrit :
> That being said with an ocaml rewrite I'd abstract the thing a little bit more to make it more DRY (I deliberately prevented myself of doing that in sh: possible but guaranteed to become un-rereadable once you figured out the magic invocations)

This is now done and available as topkg — the trivial OCaml package builder.

https://github.com/dbuenzli/topkg

The approach is extensively documented which should help packagers and package developers that wish to take the same simplistic approach if it can work for them. I also made it build system independent. Feedback welcome.  

Best,

Daniel

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

[Adrien Nader]

On Fri, Apr 11, 2014, David Allsopp wrote:
> Daniel Bünzli wrote:
> > Le vendredi, 11 avril 2014 à 18:32, Daniel Bünzli a écrit :
> > 
> > > Ok thanks for the info. Will implement that once I get some free time in
> > my hands.
> > 
> > I may also take that as an opportunity to rewrite these *trivial* shell
> > scripts in ocaml for improving windows compatibility. Here are a few
> > questions to the list:
> > 
> > 1) What should I use for #!,  /usr/bin/env ocaml  ? And what will windows
> > do with that ?
> 
> Windows can't do anything with that. However, most people compiling OCaml packages on Windows expect to use bash (either from Cygwin or MSYS), where the scripts would run as on Unix. Are you sure that Windows compatibility is already a problem?
> 
> > 2) The only OS related things I do is write the .install file and invoke
> > ocamlbuild once with all the targets that need to be build. Is Sys.command
> > enough for that ? and is the invocation syntax identical ?
> 
> As long as you don't do anything exotic with command line parameters (quoting can be very weird for the Windows command processor, cmd, which is what Sys.command uses) then yes, Sys.command will be fine, and the same as on Unix.
> 
> In passing, it does have to be said that getting Windows support automatically from your build system is something that OASIS does...

Actually you can do OCaml using the Mingw port while not using Cygwin or
Msys except for an implementation issue in ocaml/ocamlbuild because of
Windows awful "shell" escaping. It is not very difficult to solve (and
ocaml from svn is heading that way).

-- 
Adrien Nader

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

[Adrien Nader]

On Sat, Apr 12, 2014, Adrien Nader wrote:
> On Fri, Apr 11, 2014, David Allsopp wrote:
> > Daniel Bünzli wrote:
> > > Le vendredi, 11 avril 2014 à 18:32, Daniel Bünzli a écrit :
> > > 
> > > > Ok thanks for the info. Will implement that once I get some free time in
> > > my hands.
> > > 
> > > I may also take that as an opportunity to rewrite these *trivial* shell
> > > scripts in ocaml for improving windows compatibility. Here are a few
> > > questions to the list:
> > > 
> > > 1) What should I use for #!,  /usr/bin/env ocaml  ? And what will windows
> > > do with that ?
> > 
> > Windows can't do anything with that. However, most people compiling OCaml packages on Windows expect to use bash (either from Cygwin or MSYS), where the scripts would run as on Unix. Are you sure that Windows compatibility is already a problem?
> > 
> > > 2) The only OS related things I do is write the .install file and invoke
> > > ocamlbuild once with all the targets that need to be build. Is Sys.command
> > > enough for that ? and is the invocation syntax identical ?
> > 
> > As long as you don't do anything exotic with command line parameters (quoting can be very weird for the Windows command processor, cmd, which is what Sys.command uses) then yes, Sys.command will be fine, and the same as on Unix.
> > 
> > In passing, it does have to be said that getting Windows support automatically from your build system is something that OASIS does...
> 
> Actually you can do OCaml using the Mingw port while not using Cygwin or
> Msys except for an implementation issue in ocaml/ocamlbuild because of
> Windows awful "shell" escaping. It is not very difficult to solve (and
> ocaml from svn is heading that way).
> 

Sorry, forgot to mention that this included building software through
oasis and ocamlbuild. From configure of libraries to build the final
executable. And that has been the case for 3 years at least.

-- 
Adrien Nader

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

[Daniel Bünzli]

Le samedi, 12 avril 2014 à 09:44, Adrien Nader a écrit :

> Sorry, forgot to mention that this included building software through
> oasis and ocamlbuild. From configure of libraries to build the final
> executable. And that has been the case for 3 years at least.

Does that change his answer (i.e. that a shell interpreter will be available) ?

Daniel

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

[Adrien Nader]

On Sat, Apr 12, 2014, Daniel Bünzli wrote:
> 
> 
> Le samedi, 12 avril 2014 à 09:44, Adrien Nader a écrit :
> 
> > Sorry, forgot to mention that this included building software through
> > oasis and ocamlbuild. From configure of libraries to build the final
> > executable. And that has been the case for 3 years at least.
> 
> Does that change his answer (i.e. that a shell interpreter will be available) ?

The requirements for ocamlbuild on windows _right_ _now_ include
bash.exe (not "sh" iirc) because of Sys.command (!) and a few tools like
cp, mv, find, mkdir.

This is far from enough for typical shell scripting and probably barely
enough for shell scripts which are carefully crafted to rely as little
as possible on anything that isn't a shell builtin. This looks like a
dead-end to me.

Moreover, the reliance on mv, cp and friends in ocamlbuild is probably
only justified by the need to have a (ba)sh.exe anyway. If this
requirement goes away, I expect the other shell-outs to go away too.

This isn't very high in the todo list for ocamlbuild and  but it would
simplify some OCaml installations on Windows and would make builds much
much faster (spawning processes in Cygwin/Msys is very slow since they
emulate fork without kernel support).

In a few words, today you can expect a posix shell but this isn't very
future-proof. However I'd probably not change much the current build
system: process management in OCaml is more work than in shell and a
arewrite would take time for little benefit, all while the environment
is evolving rapidly.

-- 
Adrien Nader

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

[Daniel Bünzli]

Le samedi, 12 avril 2014 à 13:41, Adrien Nader a écrit :

> In a few words, today you can expect a posix shell but this isn't very
> future-proof. However I'd probably not change much the current build
> system: process management in OCaml is more work than in shell and a
> arewrite would take time for little benefit, all while the environment
> is evolving rapidly.

Future-proof is what interests me. In my case the package build script needs a single ocamlbuild invocation and write one (.install) file so that wouldn't be atrocious to manage, there's no cp, mv, install etc, I leave that to my friend opam-installer. Actually I'm interested in rewriting these script in .ml for readability, abstraction and maybe having a more readable command line interface through a handful of combinators and the Arg module. So if these things become ml scripts the cross platform way of invoking them would then just become:  

    ocaml pkg/build

rather than just

    pkg/build

that would take care of the fact that windows wouldn't understand #!/usr/bin/env ocaml ?

Daniel

P.S. Is there any tutorial/instructions that shows us how ocaml development occurs/should be done on windows ? Packager instructions about dos and don'ts would be helpful too.  

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

[Adrien Nader]

On Sat, Apr 12, 2014, Daniel Bünzli wrote:
> 
> 
> Le samedi, 12 avril 2014 à 13:41, Adrien Nader a écrit :
> 
> > In a few words, today you can expect a posix shell but this isn't very
> > future-proof. However I'd probably not change much the current build
> > system: process management in OCaml is more work than in shell and a
> > arewrite would take time for little benefit, all while the environment
> > is evolving rapidly.
> 
> Future-proof is what interests me. In my case the package build script needs a single ocamlbuild invocation and write one (.install) file so that wouldn't be atrocious to manage, there's no cp, mv, install etc, I leave that to my friend opam-installer. Actually I'm interested in rewriting these script in .ml for readability, abstraction and maybe having a more readable command line interface through a handful of combinators and the Arg module. So if these things become ml scripts the cross platform way of invoking them would then just become:  
> 
>     ocaml pkg/build
> 
> rather than just
> 
>     pkg/build
> 
> that would take care of the fact that windows wouldn't understand #!/usr/bin/env ocaml ?

Point taken for the rewrite to OCaml.

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.

All the build system I've seen that started as part of another project
have either gotten larger than what they wanted to replace while still
not matching functionalities or have gotten abandoned, probably after a
painful desperation and madness phase for their maintainers.

tl;dr: if you roll your own build system as part of an existing project,
don't try to be comprehensive or you'll most likely do worse than what
you were trying to avoid. Keep it simple so that at least it's easy for
anyone to learn and debug.

As for the original question, "ocaml foo" should replace the shebang.

> P.S. Is there any tutorial/instructions that shows us how ocaml development occurs/should be done on windows ? Packager instructions about dos and don'ts would be helpful too.  

I'm not aware of such a resource.

From my point of view, most rules are not specific to Windows: use
ocamlfind, handle DESTDIR one way or another, try to not hardcode paths.

Now, the Windows specifics.

The first thing to be aware on Windows is fragmentation. (that was just
too tempting to mention after hearing so much about the distribution
fragmentation on Linux :) ).

Anyway. Constant: your code will be running against the Win32 API and
use Microsoft's libraries (msvcrt*.dll for instance).
Variables: compilers and environments in which they run.

C compilers can be Visual Studio (MSVC), GCC native (i.e. mingw*), GCC
Cygwin (I'll leave this one out for the obvious reason), LLVM, probably
still some Borland and others.

Environments can be: native windows, msys, cygwin, Interix/SFU/SUA (now
dead).
- native windows doesn't need an additional description.
- cygwin provides you with a mostly POSIX environment.
- msys (a fork of Cygwin with some things like automatic translation of
  command-line arguments or environment variables like "/opt/foo" to
  "C:\\Msys\\opt\\foo" when an msys application starts a native windows
  application) provides you with something that looks like a POSIX
  environment (the goal was to run ./configure, no more, no less).

Keep in mind that running tools in Cygwin and building for native
windows is perfectly valid and is actually encouraged for OCaml. It is
simply cross-compilation with the special case that the system which
compiles can also run the binaries it has compiled.

Chose the tools and environments you want to support. Most constraints
should then be obvious.

Worth mentionning, CMake and LLVM have chosen to go the MSVC-route
mostly.
By doing so, cmake has also chosen to not rely on pkg-config and to
instead use heuristics to locate libraries; it's not something I agree
with but it's a valid choice.
As for LLVM, they've chosen to basically create "msvclang", i.e. a
compiler which masquerades as cl.exe (msvc's command-line compiler) and
mimics its command-line interface and error messages.

I hope this was clear enough and not too unreadable.

-- 
Adrien Nader

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

[Anil Madhavapeddy]

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.

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 do like the fact that I can glance at Daniel's repositories and
understand what's going on in minutes rather than days...

-anil

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

[Adrien Nader]

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

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

[Daniel Bünzli]

Le dimanche, 13 avril 2014 à 13:17, Adrien Nader a écrit :
> 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).

Pure beauty.



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

Well if most people get it wrong, I'd rather suggest that the tools are. Blaming people rarely solves problems.

Thanks for the hints about windows,  

Daniel

Re: [Caml-list] [ANN] React 1.0.1

[Daniel Bünzli]

Le mardi, 8 avril 2014 à 03:04, Daniel Bünzli a écrit :

> In fact it's so trivial that I managed to get it wrong (signals can't be compared structurally, it may raise). I'll do a bug fix release in a few days

react 1.0.1 has been released to fix that. Change log:

https://github.com/dbuenzli/react/blob/master/CHANGES.md

Best,

Daniel

Re: [Caml-list] [ANN] React 1.1.0

[Daniel Bünzli]

Le lundi, 21 avril 2014 à 20:18, Daniel Bünzli a écrit :
> react 1.0.1 has been released to fix that.

There was still a bug in the initialization of the rank S.switch'ed signals which wasn't captured by the test suite. It now is and we have react 1.1.0. A few new combinators (e.g. for dealing with options) were also added. Details here:

https://github.com/dbuenzli/react/blob/master/CHANGES.md

Best,

Daniel

Re: [Caml-list] [ANN] React 1.1.0

[Daniel Bünzli]

Le dimanche, 27 avril 2014 à 22:33, Daniel Bünzli a écrit :

> There was still a bug in the initialization of the rank S.switch'ed signals which wasn't captured by the test suite. It now is and we have react 1.1.0. A few new combinators (e.g. for dealing with options) were also added.

This new implementation of S.switch is becoming embarrassing. Uncovered a new bug here [1]. It's fixed.  

New release coming in a few days, I want to wait a little bit to see if I uncover other things.  

Sorry for the inconvenience,  

Daniel

[1] https://github.com/dbuenzli/react/issues/7