caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
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.
> 




  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;
as well as URLs for NNTP newsgroup(s).