[Caml-list] Suggested way to determine platform specific capabilities in build system?

[Caml-list] Suggested way to determine platform specific capabilities in build system?

[Malcolm Matalka]

Hello,

What is the current suggested way to determine what, roughly, autoconf
would do for you?  I have some platform specific functionality to be
included (or excluded) depending on the OS.

Thanks,
/Malcolm

Re: [Caml-list] Suggested way to determine platform specific capabilities in build system?

[Daniel Bünzli]

Le mardi, 14 avril 2015 à 12:51, Malcolm Matalka a écrit :
> What is the current suggested way to determine what, roughly, autoconf
> would do for you? I have some platform specific functionality to be
> included (or excluded) depending on the OS.

I don't know if there's a suggested way but here are various ways to proceed.

If you are using ocamlbuild, you can use `Sys.win32` since 4.01.0 or `Sys.os_type = "Win32"` to determine if you are on windows and otherwise get the (stripped and lowercased) result of `uname -s`, see e.g (but it's missing the win bit):  

https://github.com/dbuenzli/tsdl/blob/master/myocamlbuild.ml#L6

If you are using Makefiles you may want include `$(ocamlc -where)/lib/ocaml/Makefile.config` and use the `$SYSTEM` variable.

If this is only needed for C stubs you can also try solve this at the CPP level — but I guess this can be quite brittle — see e.g (here again missing the win bit as it's undefined for now):  

https://github.com/dbuenzli/mtime/blob/master/src-os/mtime_stubs.c#L11-L21

In any case make sure the value can be overridden from the command line for cross compilation scenarios.  

Best,

Daniel

Re: [Caml-list] Suggested way to determine platform specific capabilities in build system?

[Thomas Gazagnaire]

>> What is the current suggested way to determine what, roughly, autoconf
>> would do for you? I have some platform specific functionality to be
>> included (or excluded) depending on the OS.
> 
> I don't know if there's a suggested way but here are various ways to proceed.
> 
> If you are using ocamlbuild, you can use `Sys.win32` since 4.01.0 or `Sys.os_type = "Win32"` to determine if you are on windows and otherwise get the (stripped and lowercased) result of `uname -s`, see e.g (but it's missing the win bit):  
> 
> https://github.com/dbuenzli/tsdl/blob/master/myocamlbuild.ml#L6
> 
> If you are using Makefiles you may want include `$(ocamlc -where)/lib/ocaml/Makefile.config` and use the `$SYSTEM` variable.
> 
> If this is only needed for C stubs you can also try solve this at the CPP level — but I guess this can be quite brittle — see e.g (here again missing the win bit as it's undefined for now):  
> 
> https://github.com/dbuenzli/mtime/blob/master/src-os/mtime_stubs.c#L11-L21
> 
> In any case make sure the value can be overridden from the command line for cross compilation scenarios.  

See also the system detection functions in opam-depext:

https://github.com/ocaml/opam-depext/blob/master/depext.ml#L76

Thomas

Re: [Caml-list] Suggested way to determine platform specific capabilities in build system?

[Adrien Nader]

Hi,

On Tue, Apr 14, 2015, Daniel Bünzli wrote:
> Le mardi, 14 avril 2015 à 12:51, Malcolm Matalka a écrit :
> > What is the current suggested way to determine what, roughly, autoconf
> > would do for you? I have some platform specific functionality to be
> > included (or excluded) depending on the OS.
> 
> I don't know if there's a suggested way but here are various ways to proceed.
> 
> If you are using ocamlbuild, you can use `Sys.win32` since 4.01.0 or `Sys.os_type = "Win32"` to determine if you are on windows and otherwise get the (stripped and lowercased) result of `uname -s`, see e.g (but it's missing the win bit):  
> 
> https://github.com/dbuenzli/tsdl/blob/master/myocamlbuild.ml#L6
> 
> If you are using Makefiles you may want include `$(ocamlc -where)/lib/ocaml/Makefile.config` and use the `$SYSTEM` variable.
> 
> If this is only needed for C stubs you can also try solve this at the CPP level — but I guess this can be quite brittle — see e.g (here again missing the win bit as it's undefined for now):  
> 
> https://github.com/dbuenzli/mtime/blob/master/src-os/mtime_stubs.c#L11-L21
> 
> In any case make sure the value can be overridden from the command line for cross compilation scenarios.  

This is the wrong approach. Please do not test for systems but for
capabilities. Testing for systems hinders progress and is a huge
long-term cost.

Consider the case where you test for windows on the mingw-w64 toolchain.
Something isn't available and you therefore disable it. Then mingw-w64
add it and tt becomes available at the end of the year.
Either you must push a new release (typically a development one that is
completely experimental) or the packager must patch (and that's one of
the most annoying kind of patching to do) or the software never takes
advantage of the new feature.

The proper way to do it is to test for features instead. Want to know if
function foo is available in library bar? Well, just reference it and
see if compilation and/or linking fails. You can also try to run it, if
not cross-compiling; at which point you would have to guess (in practice
it's < 1% of cases).

-- 
Adrien Nader

Re: [Caml-list] Suggested way to determine platform specific capabilities in build system?

[Daniel Bünzli]

Le dimanche, 19 avril 2015 à 08:47, Adrien Nader a écrit :
> This is the wrong approach. Please do not test for systems but for
> capabilities. Testing for systems hinders progress and is a huge
> long-term cost.

It depends quite a lot of what you need to do, e.g. in the ocamlbuild example I linked to, you need to add a specific flag to the compiler, now if you need to check for this using some kind of obscure test your are building quite a few assumptions about how the tool works and the semantics of the flag both of which may change in the future regardless of the you may think about them. These kind of things lead to quite obscure configuration systems which also do have a huge cost both for *users* and maintainers in the long-term.

> The proper way to do it is to test for features instead. Want to know if
> function foo is available in library bar? Well, just reference it and
> see if compilation and/or linking fails.  

I know this is the way autocrap likes to work; it may seem smart but I think that's completely retarded. We want versioned APIs/system releases that are clear about the symbols they expose and their associated semantics. I mean if we take to the extreme why have any form of package constraints in opam ? We could just test needed symbols/modules against what is installed. I hope you do realize that this is completely insane.   

Nowadays that it has never been as easy to use a patched package (under the form of `opam pin`) and that I hope we will also soon fix the problem of making reliable releases in a breeze. I think that the kind of approach you propose is going to be more much more expensive in the long term. The simpler you keep the configuration bits the easier it will be to adapt both from you as a maintainer or from someone that is external to the project.  

The approach you mention would make sense if the OSes would provide us a reliable service for testing its capabilities. Lacking this, relying on obscure and brittle test shell scripts, thanks but no. Progress is not hindered by what you make think...

Best,

Daniel

RE: [Caml-list] Suggested way to determine platform specific capabilities in build system?

[David Allsopp]

Daniel Bünzli wrote:
> Le dimanche, 19 avril 2015 à 08:47, Adrien Nader a écrit :

<snip>

> > The proper way to do it is to test for features instead. Want to know
> > if function foo is available in library bar? Well, just reference it
> > and see if compilation and/or linking fails.
> 
> I know this is the way autocrap likes to work; it may seem smart but I
> think that's completely retarded.

Um, while your arguments often veer a little towards ad hominem attacks, the word "retarded" used in this context is extremely offensive, even if that is not what you intended (making allowance that while your English is extremely good, it is not your first language).

One of the many nice things about this email list is that the language used on it is generally civil!

I apologise if it turns out that I'm only person mildly offended...


David

Re: [Caml-list] Suggested way to determine platform specific capabilities in build system?

[Daniel Bünzli]

Le dimanche, 19 avril 2015 à 12:13, David Allsopp a écrit :
> > I know this is the way autocrap likes to work; it may seem smart but I
> > think that's completely retarded.
>  
> Um, while your arguments often veer a little towards ad hominem attacks, the word "retarded" used in this context is extremely offensive, even if that is not what you intended (making allowance that while your English is extremely good, it is not your first language).

I don't see any ad hominem attack here I'm criticizing tools and approaches — if Adrien think there is one, I'm sorry and tell him he should not take it as such.

Regarding the sentence you mention I'll rephrase it just for you (or any other person I may have offended):

❀ I know this is the way autoheaven likes to work, however it seems that while I can appreciate that this technique has his merits I do have slight concerns with it. ❀

Best,

Daniel

Re: [Caml-list] Suggested way to determine platform specific capabilities in build system?

[Emmanuel Surleau]

On Sun, Apr 19, 2015 at 2:11 PM, Daniel Bünzli
<daniel.buenzli@erratique.ch> wrote:
> Le dimanche, 19 avril 2015 à 12:13, David Allsopp a écrit :
>> > I know this is the way autocrap likes to work; it may seem smart but I
>> > think that's completely retarded.
>>
>> Um, while your arguments often veer a little towards ad hominem attacks, the word "retarded" used in this context is extremely offensive, even if that is not what you intended (making allowance that while your English is extremely good, it is not your first language).
>
> I don't see any ad hominem attack here I'm criticizing tools and approaches — if Adrien think there is one, I'm sorry and tell him he should not take it as such.
>
> Regarding the sentence you mention I'll rephrase it just for you (or any other person I may have offended):
>
> ❀ I know this is the way autoheaven likes to work, however it seems that while I can appreciate that this technique has his merits I do have slight concerns with it. ❀


While I agree with David about the form, I agree with you about the
content. Using version numbers brings its own pains, but all in all it
is considerably more reliable than the other solutions.

Cheers,

Emm

Re: [Caml-list] Suggested way to determine platform specific capabilities in build system?

[Ben Millwood]

[-- Attachment #1: Type: text/plain, Size: 2164 bytes --]

I agree with David that use of the term "retarded" is offensive and
inappropriate in this or pretty much any context. "Mental retardation" was
until quite recently (and in some places still is) an official sanctioned
medical definition and using it to mean "clearly wrong", "unpleasant" or
"not worth dealing with" is to tell people who had been diagnosed with that
condition that they are clearly wrong, unpleasant, or not worth dealing
with. Regardless of your opinion about autoconf, that's clearly not
something that any of us want.

On 19 April 2015 at 20:14, Emmanuel Surleau <emmanuel.surleau@gmail.com>
wrote:

> On Sun, Apr 19, 2015 at 2:11 PM, Daniel Bünzli
> <daniel.buenzli@erratique.ch> wrote:
> > Le dimanche, 19 avril 2015 à 12:13, David Allsopp a écrit :
> >> > I know this is the way autocrap likes to work; it may seem smart but I
> >> > think that's completely retarded.
> >>
> >> Um, while your arguments often veer a little towards ad hominem
> attacks, the word "retarded" used in this context is extremely offensive,
> even if that is not what you intended (making allowance that while your
> English is extremely good, it is not your first language).
> >
> > I don't see any ad hominem attack here I'm criticizing tools and
> approaches — if Adrien think there is one, I'm sorry and tell him he should
> not take it as such.
> >
> > Regarding the sentence you mention I'll rephrase it just for you (or any
> other person I may have offended):
> >
> > ❀ I know this is the way autoheaven likes to work, however it seems that
> while I can appreciate that this technique has his merits I do have slight
> concerns with it. ❀
>
>
> While I agree with David about the form, I agree with you about the
> content. Using version numbers brings its own pains, but all in all it
> is considerably more reliable than the other solutions.
>
> Cheers,
>
> Emm
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>

[-- Attachment #2: Type: text/html, Size: 2960 bytes --]

Re: [Caml-list] Suggested way to determine platform specific capabilities in build system?

[Ivan Gotovchits]

oasis, look at setup.data and setup.ml



> On Apr 14, 2015, at 6:51 AM, Malcolm Matalka <mmatalka@gmail.com> wrote:
> 
> Hello,
> 
> What is the current suggested way to determine what, roughly, autoconf
> would do for you?  I have some platform specific functionality to be
> included (or excluded) depending on the OS.
> 
> Thanks,
> /Malcolm
> 
> -- 
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: [Caml-list] Suggested way to determine platform specific capabilities in build system?

[Richard W.M. Jones]

On Tue, Apr 14, 2015 at 10:51:42AM +0000, Malcolm Matalka wrote:
> Hello,
> 
> What is the current suggested way to determine what, roughly, autoconf
> would do for you?  I have some platform specific functionality to be
> included (or excluded) depending on the OS.

Is there a reason not to use autoconf?  I use it all the time with
OCaml projects, eg:

https://github.com/libguestfs/libguestfs
https://github.com/libguestfs/supermin

and a random more recent example:

http://git.annexia.org/?p=mclu.git;a=tree

There are ocaml.m4 macros on ocamlforge.

Rich.

-- 
Richard Jones
Red Hat