-
Notifications
You must be signed in to change notification settings - Fork 396
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Pass ocamlc explicitly to configurator using DUNE_CONFIGURATOR #695
Conversation
|
Ah yes. We should probably add our own |
That seems fine. Regarding passing a S-expression, I guess we would indeed to move some more code to usexp. There are a lot of modules in src/ that are specialized, and when extracting them to sub-libraries, I think we should clean them up, document and generalize them a bit. That makes them easier to understand as standalone components. For the S-expression combinators, one thing I don't really like at the moment is that we end up with a discrepancy in the naming, with some functions that are named |
Indeed |
Actually, we can just issue the warning when |
OK, I implemented the check for |
79c5c91
to
86e4df8
Compare
Do we even need to keep the argument at all? Users will need to edit their jbuild file to switch from configurator to jbuilder.configurator, so we might as well remove the argument at the same time. |
Yup let's just get rid of it.
…On Thu, Apr 12, 2018, 4:48 PM Jérémie Dimino ***@***.***> wrote:
Do we even need to keep the argument at all? Users will need to edit their
jbuild file to switch from configurator to jbuilder.configurator, so we
might as well remove the argument at the same time.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#695 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAIe-wOdYyKzAbEfAvK6Slt2Csk8Cm24ks5tnyLhgaJpZM4TQJdD>
.
|
@diml ok it's gone. |
Looks good |
The simplest way of obsoleting the
-ocamlc
flag. Some notes:We are likely to still want to keep
-ocamlc
for debugging, but ideally, warn the user that this isn't necessary. Should we use theINSIDE_DUNE
variable in configurator to issue a warning when this flag is passed?Ideally,
DUNE_CONFIGURATOR
would be an s-expression containing all the config info dune wants to pass to configurator. But there's a couple of issues with this. The first one is that it's tough to write an sexp parser in configurator since theSexp
module is in dune itself. And the second issue is that we'd prefer to share the configuration record, but that would require a dependency between dune and configurator. To solve this, I guess we could makeSexp
part of usexp (or a separate, internal lib) and then have dune depend on configurator to get the record definition. Not sure if this is right however.Anyway, the contents of
DUNE_CONFIGURATOR
is an implementation detail and is easy to safely change. So we can always punt these decisions until later.