From: Yoann Padioleau <padator@wanadoo.fr>
To: kgo@grant-olson.net
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] Building multiple configurations?
Date: Mon, 22 Mar 2010 18:56:54 -0700 [thread overview]
Message-ID: <6A0948D6-EBA8-4EAD-9684-DD8CDEFE0A1C@wanadoo.fr> (raw)
In-Reply-To: <4BA81A46.1030004@grant-olson.net>
On Mar 22, 2010, at 6:32 PM, Grant Olson wrote:
>
> On 3/22/2010 9:13 PM, Yoann Padioleau wrote:
>>>
>>> I've got a configuration file that's a .ml file. And I do want it to be
>>> an .ml file that gets included at compile time, not some .txt config
>>> file that gets read in at runtime. I'm building two different versions
>>> of my app, with two different configurations.
>>
>> Why ? Why ? Why not having your app configurable with a txt file
>> or some command line flags like every other programs ?
>>
>
> Because it's an elaborate configuration.
Apparently it's a boolean since you support only 2 different configs ...
let config1 = {
field1 = 1;
field2 = true;
}
let config2 = {
field1 = 2;
field2 = true;
}
(* settable via command line or config file *)
let config = ref true
let current_config () =
if !config then config1 else config2
...
let main =
let args = [
"-config1", Arg.Set config, "";
"-config2", Arg.Clear config "";
]
in
Arg.parse ... blablabla
> I don't want to write an
> equally elaborate parser when I've already got ocaml to do that for me.
> I'd rather get a compile-time error than a runtime error if the syntax
> is bad. And the app isn't designed to be user-configured.
>
>>>
>>> Basically, I want to do the same thing as a C #ifdef:
>>>
>>> #ifdef VERSION2
>>> ... include version one
>>> #else
>>> ... include version two
>>> #endif
>>
>> People use that because they want to do different things depending on the architecture, or
>> if some dependencies are present or not. Do you have the same requirement here ?
>>
>
> They also use it for things like debug/release build. But I suppose you
> could say that the two configurations have totally different
> dependencies for these purposes.
>
> I know what I'm doing is a little weird. But I have my reasons for
> wanting to do it this way.
>
next prev parent reply other threads:[~2010-03-23 1:56 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-23 0:35 Grant Olson
2010-03-23 1:13 ` [Caml-list] " Yoann Padioleau
2010-03-23 1:32 ` Grant Olson
2010-03-23 1:56 ` Yoann Padioleau [this message]
2010-03-23 3:06 ` Grant Olson
2010-03-23 1:37 ` Michael Ekstrand
2010-03-23 1:47 ` [Caml-list] " Grant Olson
2010-03-23 8:54 ` Daniel Bünzli
2010-03-23 5:50 ` [Caml-list] " Martin Jambon
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=6A0948D6-EBA8-4EAD-9684-DD8CDEFE0A1C@wanadoo.fr \
--to=padator@wanadoo.fr \
--cc=caml-list@inria.fr \
--cc=kgo@grant-olson.net \
/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