Building multiple configurations?

Building multiple configurations?

[Grant Olson]

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

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

Re: [Caml-list] Building multiple configurations?

[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 ?

> 
> 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
> 

Re: [Caml-list] Building multiple configurations?

[Grant Olson]

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.  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.

Re: Building multiple configurations?

[Michael Ekstrand]

On 03/22/2010 07: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.
> 
> 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

Re: [Caml-list] Re: Building multiple configurations?

[Grant Olson]

[-- Attachment #1: Type: text/plain, Size: 442 bytes --]

On 3/22/2010 9:37 PM, Michael Ekstrand wrote:
> 
> 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.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 552 bytes --]

Re: [Caml-list] Building multiple configurations?

[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


> 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.
> 

Re: [Caml-list] Building multiple configurations?

[Grant Olson]

On 3/22/2010 9:56 PM, Yoann Padioleau wrote:
> 
> 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.

Re: [Caml-list] Building multiple configurations?

[Martin Jambon]

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.
> 
> 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

-- 
http://mjambon.com/

Re: [Caml-list] Re: Building multiple configurations?

[Daniel Bünzli]

On Tue, Mar 23, 2010 at 2:47 AM, Grant Olson <kgo@grant-olson.net> wrote:
> On 3/22/2010 9:37 PM, Michael Ekstrand wrote:
>>
>> 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.

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