I want to pass a -foo
flag to coqc
, for building stdlib, test-suite and CI. What should I do?
For stdlib you need to pass it in theories/dune
For test-suite it is a bit harder
lol
For individual files you can pass a flag by putting a header
for CI just fake it (change the default in coqargs)
But to change all files, you will need to change it manually in the test-suite makefile
Gaëtan Gilbert said:
for CI just fake it (change the default in coqargs)
this also works for stdlib/test suite
What I really want in the end is to be able to launch CI with and without the flags
Like two targets
CI projects are free to run coqc directly so the only solution is to modify coqc
Just always have the option on for now :)
you can make it controlled by an env var
Sorry, I mean: run the test-suite with and without the flags, in our CI
The test-suite job in the pipeline you mean?
<s>There is no simple way to change all the flags</s>
for passing flags in the test suite see what test-suite:base+async
does
Yes, ideally I want to make to copies of that job in my branch
One with the flag one without
Thanks for the suggestion, my need is very much like async indeed
(for stdlib see the base+async job)
Oh, but does this means that CI builds the stdlib not using dune? Makefile.build
strikes back?
Yes, the pr for getting rid of makefile.build is not yet finished
we will get to it next week I think
when we move to just dune, what will be the right way to pass coqc an option? I did suggest @Maxime Dénès to use a dune profile and have (profile foo (coq (flags -my-option)))
but apparently this option is not passed while building the prelude.
Ali and I are pushing some changes to coqdep that will make the job easier
Enrico Tassi said:
when we move to just dune, what will be the right way to pass coqc an option? I did suggest Maxime Dénès to use a dune profile and have
(profile foo (coq (flags -my-option)))
but apparently this option is not passed while building the prelude.
I need to think about that but as we will use gen_rules
I guess that a config for gen_rules will do
profile should also work in recent versions, but we wont use that as we will control rules locally
if that doens't work that's a bug
flags should be passed for prelude too
That is the PR https://github.com/ocaml/dune/pull/3547
Enrico Tassi said:
Oh, but does this means that CI builds the stdlib not using dune?
Makefile.build
strikes back?
depends on the job
Enrico Tassi said:
That is the PR https://github.com/ocaml/dune/pull/3547
I know that PR, that PR was buggy actually see current test suite
and https://github.com/ocaml/dune/pull/4758
Gaëtan Gilbert said:
Enrico Tassi said:
Oh, but does this means that CI builds the stdlib not using dune?
Makefile.build
strikes back?depends on the job
hopefully soon it won't
we are making progress on getting gen_rules ready
we actually removed the coqdep printing + parsing, and now we also share the context so it is quite fast
next week I have some time so hopefully we can finish it
Ah, then setting dune lang to 2.9 would have made it work for Maxime?
@Enrico Tassi not sure if we versioned the fix, maybe you can write the problem in the dune channel or bug tracker?
Dune 2.9 has the fix
Yes, I confirm I didn't version the fix
Maxime told me he has 2.9.1
so coq flags in profile are broken for 2.8 and less
I'd need to see if there is some bug remaining
post a reproduction case in the dune stream
So the "funny" part is I lost a significant part of my day trying to do it with Dune just because I didn't know the configure + make workflow was still there. I knew the COQUSERFLAGS
env var.
Am I missing something or does dune build
treat stdlib warnings as non fatal?
I mean warning emitted by Coq, this time
Last time I checked, this was still the case.
What was still the case? From what I see dune build
does not fail when stdlib emits a warning.
(to test it, you can just add Set Foobar.
in a file)
The developer profile for make
does treat them as fatal.
Still the case that Dune does not treat coqc warnings as fatal.
I see. But why is that?
Despite a bug report already being opened on the topic I think.
Incidentally, this made me completely mis-evaluate the state of my branch in parsing mode. I had a lot of debug output, so didn't see the warnings. And I was convinced they were treated as errors, like they used to be with make
.
https://github.com/coq/coq/pull/14241
Yes the current state is not the best, we need to finish the gen_rules PR ASAP
The current dune build method for vo files has a few drawbacks, exactly what was discussed on the call. Once we re-introduce gen_rules we should close all the regressions afaict
Moreover we will need developer feedback on the PR porting the test-suite to dune. The PR brings many improvements but user experience is quite different so need help
I switched back to make, to be able to pass the -only-parsing flag
but it is almost unusable
it is extremely slow (> 1s per binary/plugin to produce, probably because it makes a full call to dune each time)
when I do make clean
, I need to redo ./configure
when I replace ./configure -profile devel
to what ./configure -help
says it is equivalent to, it changes the behavior
when I replay coqc
invocations as shown by make VERBOSE=1
it fails with findlib errors
so for now, I have no concrete solution to get a workable dev setup that allows me to pass flags to coqc
do we have an ETA for the fixes?
(the point is to schedule my activity, not to put pressure)
Maxime Dénès said:
when I replace
./configure -profile devel
to what./configure -help
says it is equivalent to, it changes the behavior
Indeed, this doc is outdated. Now this profile does more.
I had severely underestimated the situation with the build system. For better efficiency, I will reschedule the activity on this patch to after these regressions are fixed.
Last updated: Sep 15 2024 at 13:02 UTC