Conditional BuildDepends

[gildor478]

This feature request has been migrated from artifact #547 on forge.ocamlcore.org. It was assigned to user102.

user102 posted on 2010-04-08 10:00:39:

It appears that in certain case a conditional BuildDepends should be very useful.

Typically with ocaml-gettext, you should be allowed to disable the i18n, leading to remove a dependency.

Maybe it is not possible, we must think about that.

user144 replied on 2016-04-12 21:16:19:

+1

I have a more complicated scenario in which I want to enable/disable a submodule depending on the presence of Lwt.

user102 replied on 2016-04-12 21:40:09:

Can you describe more precisely your use case?

It may be useful to help me make up my mind on this topic.

Here is my current status thoughts on the topic:

1. Executable should be OK.
2. Object/Library are problematic, because the generated META file will need to be generated at compile time.

Concerning 2., depending on the dependency on gettext, you will have META (with gettext): version = "X.Y.Z" requires = "unix gettext" archive(byte) = ....

META (without gettext): version = "X.Y.Z" requires = "unix" archive(byte) = ....

The only solution, I see is to not generate a META file in this case but a META.ab and to enhance the OASISFileTemplate language, like this META.ab: version = "X.Y.Z" if flag(gettext) requires = "gettext unix" else requires = "unix" endif archive(byte) = ....

But it is a lot more complex...

Simpler alternative: The META plugin fails if there is a conditional build depends.

user144 replied on 2016-04-12 22:17:54:

My use case is about the same as yours. I have a flag "lwt" that should be enabled to compile the lwt submodule. Then some preprocessing takes place (using cppo¹) to replace the submodule with an empty one if LWT is not enabled. The point is that there is a "standard" module which is useful without needing LWT. I could generate two different libraries — which is what I do now — but I like the hierarchy of the toplevel module.

¹ This project already requires lots of preprocessing, in particular to adapt to the platform and to derive the standard and LWT version from the same source file.

user144 replied on 2016-04-13 13:40:10:

In general, it may be better to generate the META file as part of the configuration process instead of the time oasis generates the setup.ml script.

user102 replied on 2016-04-13 14:16:10:

Proposals:

1. Don't create any META files during "oasis setup" Pro: less clutter in the source directory, allow cond. dep. Cons: not clear how to customize the META file (edit outside the OASIS section)

2. Always create a META.ab file during "oasis setup" Pro: flexible and allow cond. dep. Cons: when no cond. dep. nothing will have to change in this file

3. Only create a META.ab when needed, otherwise create a META: Pro: look like current way of doing things Cons: the switch in between META and META.ab won't be clear

What do you think will be the best option?

user144 replied on 2016-04-13 15:51:09:

I think the third solution is the worse because it will be hard for users to know what is going on (and if META is customized, I guess the old META.ab must remain on the disk but won't be used when a conditional is removed).

My instincts would go to solution 1 which I find more elegant. As I see it, the only reason to modify the META file in a way that will not be overwritten it to add additional sections. Given the directive XMETAExtraLines, why not do that directly from _oasis. In any case, there is no reason that, even if generated at configure time, the generated part of the META be not between OASIS_START and OASIS_STOP and so allow to add sections to this file.

user102 replied on 2016-04-13 16:01:53:

There is a good reason to not have OASIS_START/STOP, we will have to include OASISFileTemplates in setup.ml and it will make it even bigger (which is something I don't want).

This will be actually the same with solution 1. but the code is more compact.

At this point, we maybe should look at what people do with oasis/META files.

Do you know if there is a way to extract all projects using OASIS from OPAM to analyse their code ?

user144 replied on 2016-04-13 16:52:42:

Do you know if there is a way to extract all projects using OASIS from OPAM to analyse their code ?

Have a look to https://github.com/ocamllabs/cosmetrics It should not be difficult to extract all oasis projects and run checks on them.