[Caml-list] Building multiple configurations?
Grant Olson
way.
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.
Basically, I want to do the same thing as a C #ifdef:
#ifdef VERSION2
... include version one
#else
... include version two
#endif
And then the two different builds link in two different object files
that have the same interface, creating the two different versions of the
app.
At first I thought I could write out the "module" and "module type"
stuff manually, giving the same module name in two differently named
files. But this of course creates a sub-module that isn't bound to the
right namespace, and linking fails.
What I'm doing now is using the -impl flag. I've got two files:
config.ml, and config.alt. The second version builds with "-impl
config.alt" in the list of files passed to ocamlopt instead of "config.ml"
This works, but it just seems wrong. Is there a better way for me to do
this?
-Grant
_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
Yoann Padioleau
On Mar 22, 2010, at 5:35 PM, Grant Olson wrote:
>
> I'm doing something weird here and I'm thinking there has to be a better
> way.
>
> 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 ?
>
> 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 ?
Grant Olson
>>
>> 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. 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.
Michael Ekstrand
> I'm doing something weird here and I'm thinking there has to be a better
> way.
>
> 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.
>
> Basically, I want to do the same thing as a C #ifdef:
>
> #ifdef VERSION2
> ... include version one
> #else
> ... include version two
> #endif
You can get that kind of behavior, albeit in a bit more restricted
fashion, with the camlp4.macro syntax extension. It provides DEFINE,
IFDEF, etc.
> And then the two different builds link in two different object files
> that have the same interface, creating the two different versions of the
> app.
>
> At first I thought I could write out the "module" and "module type"
> stuff manually, giving the same module name in two differently named
> files. But this of course creates a sub-module that isn't bound to the
> right namespace, and linking fails.
You could also have the two different module implementations under
different names and have the build system symlink or copy the correct
one in place prior to building. In OMake, this is easy with the
'ln-or-cp' command.
- Michael
Grant Olson
>
> You could also have the two different module implementations under
> different names and have the build system symlink or copy the correct
> one in place prior to building. In OMake, this is easy with the
> 'ln-or-cp' command.
>
Exactly what I want. Now that you've pointed it out, it seems so
obvious. Just copy the files and treat the copy as a build artifact.
Thanks.
Yoann Padioleau
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
Grant Olson
>
> 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
>
>
This is getting a off topic for this list, but it's a usability issue,
not so much a technical one.
Most users will be windows users who double-click on the icon to run it.
I could create a batch file that calls the real .exe with the config
switch to activate the alternate config, but is a user going to click on
the pretty executable file with the custom icon, or the ugly batch file
icon?
I could create a stub executable to call the real one so I can get a
pretty icon, but then people will wonder why the stub breaks when they
copy it somewhere else and don't move the real executable.
I could do some black magic and detect the executable name at runtime,
and set the config based on that, but there's no reason someone
shouldn't be able to hit F2 and rename the file.
So I'd rather just have two stand-alone executables that contain
everything they need.
Martin Jambon
> I'm doing something weird here and I'm thinking there has to be a better
> way.
>
> 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.
>
> Basically, I want to do the same thing as a C #ifdef:
>
> #ifdef VERSION2
> ... include version one
> #else
> ... include version two
> #endif
I implemented a "C preprocessor" for OCaml called cppo that lets you do that.
It may not be the best choice here but I think it's worth some advertising:
http://martin.jambon.free.fr/cppo.html
Martin
Daniel Bünzli
A similar way is to just put them in two different directories under
the same name and include the right one depending on what you want
(makes the solution more cross-platform).
Best,
Daniel