* [Caml-list] Suggested way to determine platform specific capabilities in build system?
@ 2015-04-14 10:51 Malcolm Matalka
2015-04-14 11:23 ` Daniel Bünzli
` (2 more replies)
0 siblings, 3 replies; 11+ messages in thread
From: Malcolm Matalka @ 2015-04-14 10:51 UTC (permalink / raw)
To: caml-list
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Caml-list] Suggested way to determine platform specific capabilities in build system?
2015-04-14 10:51 [Caml-list] Suggested way to determine platform specific capabilities in build system? Malcolm Matalka
@ 2015-04-14 11:23 ` Daniel Bünzli
2015-04-14 13:17 ` Thomas Gazagnaire
2015-04-19 6:47 ` Adrien Nader
2015-04-17 10:38 ` Ivan Gotovchits
2015-04-21 21:36 ` Richard W.M. Jones
2 siblings, 2 replies; 11+ messages in thread
From: Daniel Bünzli @ 2015-04-14 11:23 UTC (permalink / raw)
To: Malcolm Matalka; +Cc: caml-list
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Caml-list] Suggested way to determine platform specific capabilities in build system?
2015-04-14 11:23 ` Daniel Bünzli
@ 2015-04-14 13:17 ` Thomas Gazagnaire
2015-04-19 6:47 ` Adrien Nader
1 sibling, 0 replies; 11+ messages in thread
From: Thomas Gazagnaire @ 2015-04-14 13:17 UTC (permalink / raw)
To: Daniel Bünzli; +Cc: Malcolm Matalka, caml-list
>> 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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Caml-list] Suggested way to determine platform specific capabilities in build system?
2015-04-14 10:51 [Caml-list] Suggested way to determine platform specific capabilities in build system? Malcolm Matalka
2015-04-14 11:23 ` Daniel Bünzli
@ 2015-04-17 10:38 ` Ivan Gotovchits
2015-04-21 21:36 ` Richard W.M. Jones
2 siblings, 0 replies; 11+ messages in thread
From: Ivan Gotovchits @ 2015-04-17 10:38 UTC (permalink / raw)
To: Malcolm Matalka; +Cc: caml-list
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Caml-list] Suggested way to determine platform specific capabilities in build system?
2015-04-14 11:23 ` Daniel Bünzli
2015-04-14 13:17 ` Thomas Gazagnaire
@ 2015-04-19 6:47 ` Adrien Nader
2015-04-19 8:38 ` Daniel Bünzli
1 sibling, 1 reply; 11+ messages in thread
From: Adrien Nader @ 2015-04-19 6:47 UTC (permalink / raw)
To: Daniel Bünzli; +Cc: Malcolm Matalka, caml-list
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Caml-list] Suggested way to determine platform specific capabilities in build system?
2015-04-19 6:47 ` Adrien Nader
@ 2015-04-19 8:38 ` Daniel Bünzli
2015-04-19 10:13 ` David Allsopp
0 siblings, 1 reply; 11+ messages in thread
From: Daniel Bünzli @ 2015-04-19 8:38 UTC (permalink / raw)
To: Adrien Nader; +Cc: Malcolm Matalka, caml-list
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: [Caml-list] Suggested way to determine platform specific capabilities in build system?
2015-04-19 8:38 ` Daniel Bünzli
@ 2015-04-19 10:13 ` David Allsopp
2015-04-19 12:11 ` Daniel Bünzli
0 siblings, 1 reply; 11+ messages in thread
From: David Allsopp @ 2015-04-19 10:13 UTC (permalink / raw)
To: Daniel Bünzli, Adrien Nader; +Cc: Malcolm Matalka, caml-list
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Caml-list] Suggested way to determine platform specific capabilities in build system?
2015-04-19 10:13 ` David Allsopp
@ 2015-04-19 12:11 ` Daniel Bünzli
2015-04-19 19:14 ` Emmanuel Surleau
0 siblings, 1 reply; 11+ messages in thread
From: Daniel Bünzli @ 2015-04-19 12:11 UTC (permalink / raw)
To: David Allsopp; +Cc: Adrien Nader, Malcolm Matalka, caml-list
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Caml-list] Suggested way to determine platform specific capabilities in build system?
2015-04-19 12:11 ` Daniel Bünzli
@ 2015-04-19 19:14 ` Emmanuel Surleau
2015-04-20 9:55 ` Ben Millwood
0 siblings, 1 reply; 11+ messages in thread
From: Emmanuel Surleau @ 2015-04-19 19:14 UTC (permalink / raw)
To: Daniel Bünzli
Cc: David Allsopp, Adrien Nader, Malcolm Matalka, caml-list
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Caml-list] Suggested way to determine platform specific capabilities in build system?
2015-04-19 19:14 ` Emmanuel Surleau
@ 2015-04-20 9:55 ` Ben Millwood
0 siblings, 0 replies; 11+ messages in thread
From: Ben Millwood @ 2015-04-20 9:55 UTC (permalink / raw)
To: Emmanuel Surleau
Cc: Daniel Bünzli, David Allsopp, Adrien Nader, Malcolm Matalka,
caml-list
[-- 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 --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Caml-list] Suggested way to determine platform specific capabilities in build system?
2015-04-14 10:51 [Caml-list] Suggested way to determine platform specific capabilities in build system? Malcolm Matalka
2015-04-14 11:23 ` Daniel Bünzli
2015-04-17 10:38 ` Ivan Gotovchits
@ 2015-04-21 21:36 ` Richard W.M. Jones
2 siblings, 0 replies; 11+ messages in thread
From: Richard W.M. Jones @ 2015-04-21 21:36 UTC (permalink / raw)
To: Malcolm Matalka; +Cc: caml-list
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
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2015-04-21 21:36 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-04-14 10:51 [Caml-list] Suggested way to determine platform specific capabilities in build system? Malcolm Matalka
2015-04-14 11:23 ` Daniel Bünzli
2015-04-14 13:17 ` Thomas Gazagnaire
2015-04-19 6:47 ` Adrien Nader
2015-04-19 8:38 ` Daniel Bünzli
2015-04-19 10:13 ` David Allsopp
2015-04-19 12:11 ` Daniel Bünzli
2015-04-19 19:14 ` Emmanuel Surleau
2015-04-20 9:55 ` Ben Millwood
2015-04-17 10:38 ` Ivan Gotovchits
2015-04-21 21:36 ` Richard W.M. Jones
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).