From: Alan Schmitt <alan.schmitt@inria.fr>
To: OCAML <caml-list@inria.fr>
Subject: Re: Portability of applications written in OCAML: C stuff
Date: Thu, 24 Feb 2000 15:04:32 +0000 [thread overview]
Message-ID: <20000224150432.A9997@alan-schm1p.dns.microsoft.com> (raw)
In-Reply-To: <38B49DBD.8DCBB87A@in.ot.com.au>; from maxs@in.ot.com.au on Thu, Feb 24, 2000 at 01:55:57PM +1100
..
>In particular, while my product is currently Unix only, the build
>process
>must work under Windows too, which rules out make, autoconf, and other
>such silliness. :-)
I gather this rules out using a compiler too ... ;-)
In particular, when you say "must work under windows", do you mean out
of the box window, or one with some tools installed (ocaml, python,
cygwin thus bash, make ...)
> pcre cannot build without config.h, and neither can mlgtk.
>So there is a conflict, since both require a file called 'config.h'.
I have many "config.h" in many source distributions in my /usr/src
directory. I have never had such a problem. Actually, most of the
time, to build an application you don't need to build the
library. You actually require that it is there (and the nice thing is
you can make your ./configure check for it). Librairies and include
files are installed in some canonical places which can be looked up,
or non-canonical which can be explicitely given to the installation
script.
>> > PLEASE use filenames that are specialised to your package,
>> > do NOT use generic names on the assumption your code will
>> > be built with your Makefile in a separate directory.
>>
>> This is impossible.
>
> It is not impossible to try.
True, but since there is a nice mechanism to deal with this (ie
Makefile and directories), is this really worth it ?
Do you think we should adopt the java convention for naming ? This
would be a pain ...
Alan Schmitt
--
The hacker: someone who figured things out and made something cool happen.
next prev parent reply other threads:[~2000-02-24 17:48 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-02-15 13:01 Portability of applications written in OCAML Claude Marche
2000-02-16 13:09 ` Jean-Francois Monin
2000-02-16 14:08 ` Claude Marche
2000-02-16 14:28 ` Jean-Francois Monin
2000-02-18 9:18 ` Patrick Goldbronn - SYSCO
2000-02-16 22:49 ` Gerd Stolpmann
2000-02-18 9:36 ` Xavier Leroy
2000-02-21 20:45 ` skaller
2000-02-22 8:13 ` Sven LUTHER
2000-02-22 9:21 ` Xavier Leroy
2000-02-22 23:43 ` Portability of applications written in OCAML: C stuff Max Skaller
2000-02-23 18:31 ` Markus Mottl
2000-02-24 2:55 ` Max Skaller
2000-02-24 14:44 ` Sven LUTHER
2000-02-24 15:04 ` Alan Schmitt [this message]
2000-02-24 23:51 ` Max Skaller
2000-02-25 8:37 ` Alan Schmitt
2000-02-25 16:58 ` skaller
2000-02-24 20:17 ` Gerd Stolpmann
2000-02-25 0:35 ` Max Skaller
2000-02-25 13:21 ` STARYNKEVITCH Basile
2000-02-17 8:05 ` Portability of applications written in OCAML skaller
2000-02-25 12:29 Portability of applications written in OCAML: C stuff Juergen Pfitzenmaier
2000-02-25 16:51 ` skaller
2000-02-25 14:05 Juergen Pfitzenmaier
2000-02-26 18:47 Juergen Pfitzenmaier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20000224150432.A9997@alan-schm1p.dns.microsoft.com \
--to=alan.schmitt@inria.fr \
--cc=caml-list@inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox