Running make -f Makefile.dune test-suite
, I get:
dune runtest --no-buffer
ocamlc test-suite/.ocaml_pwd.eobjs/byte/dune__exe__Ocaml_pwd.{cmi,cmo,cmt}
ocamlopt test-suite/.ocaml_pwd.eobjs/native/dune__exe__Ocaml_pwd.{cmx,o}
ocamlopt test-suite/ocaml_pwd.exe
ocaml_pwd test-suite/bin.inc
ocaml_pwd test-suite/libpath.inc
make[1]: Entering directory '/home/mdenes/dev/coq/master/_build/default/test-suite'
cp .csdp.cache.test-suite .csdp.cache
cp: cannot create regular file '.csdp.cache': Permission denied
Does it ring a bell? Stdlib builds fine, so it is a bit strange. The files produced in _build/default
have indeed read-only permissions.
Deleting _build
and rebuilding does not fix the problem.
It's probably best not to use the top makefile for the test-suite for the moment
Just do make -C test-suite
the Makefile.dune test suite target is terrible, but trying to remove it seems like it leads to a political fight so users can keep the pain
Pffff
I agree that it doesn't make sense to keep this target until the test-suite is properly dunerized (which I have no idea when it will happen).
Should I open a PR?
also if you do make -C test-suite next time you run dune it will complain about summary.log because of this target
is dune build && make -C test-suite
expected to work?
y
Thanks, will try. But we need an ETA for fixing the mess. Removing non-working targets looks like a very clear win.
We can add them back when they are ready.
I am in favor of removing the test-suite targets from the main makefile.
The plan is to eventually remove the makefile for the test-suite, but the ETA for that is unknown. When that happens, correct targets in the main makefile can be added again.
please don't change the toplevel commands again, I am starting to get feed up to have to relearn muscle memory every two weeks
make test-suite
needs to do the job, whatever it does
(in dune mode, that is)
So how do I fix my problem?
I guess I'd need a bit more than "don't use it", then :)
@Pierre-Marie Pédrot are you able to use make test-suite currently?
Ali Caglayan said:
Pierre-Marie Pédrot are you able to use make test-suite currently?
Btw, don't we have a CI to answer this kind of questions?
The test-suite jobs don't use these targets anyway
Actually, test-suite:edge:dune does
That seems a problem with dune cache + test suite, what dune version are you using?
maybe we should pass --cache=disabled to that target
2.9.3
Is the cache enabled by default?
no
but that's a global setting
3.0 has a cache rewrite, anyways it is much faster for dev work, but I think that problem may not be fixed by the 3.0 cache rewrite
but just the speedup for zero builds is very large
λ cat ~/.config/dune/config
(lang dune 2.8)
(display short)
how do I check if it is enabled?
it seems it is not,
I don't know how to check other than the log
FWIW make test-suite works for me but I'm not a cache user
I guess a bug report with full info may help to see what the problem is
full info I mean "reproduction instructions"
tho as I meintoned the other day, more info on why the flags field doens't work for you, would be nice
maybe there is a bug in how we handle the prelude, but that'd be an obvious one line fix for 2.9.4
The pb with broken build systems is a bit like with UIs, building a repro case may be hard when reaching the inconsistent state takes a few specific steps.
But I'll try
Maxime Dénès said:
The pb with broken build systems is a bit like with UIs, building a repro case may be hard when reaching the inconsistent state takes a few specific steps.
Indeed that's a problem.
Do we have an ETA for conversion of the test suite build to dune?
Not asking this to put pressure, it could be more effective for me to just wait.
For now the experience is I spend 50% on my dev time on build issues, but I'm confident it is going to be much better once the few big issues are fixed.
(and the make vs dune redundancy resolved)
However, without an estimate on when it lands, I can't take an informed decision on how to schedule my work.
I don't know how to give an ETA
I think we should discuss it, because I think we'll need it, maybe under some hypotheses. All core dev activity is potentially impacted by work on the build system, by definition.
Is there a precise description on the next steps written somewhere, in a very detailed way that could serve as a basis for estimating the resources needed?
(maybe a collection of low level issues)
I think I found the root of the pb
make clean
does (among other things) :
find _build_vo/default//lib/coq/ test-suite \( -name '*.vo' -o -name '*.vio' -o -name '*.vos' -o -name '*.vok' -o -name '*.glob' \) -exec rm -f {} +
it does not delete .log
files
and then, when running make -f Makefile.dune test-suite
, unlike other targets, it does not complain about generated artifacts in the source tree
but copies them as read-only, which then makes the build fail
So switching back to dune after a call to make, even after make clean
does not work if test suite was run. Otherwise it works fine.
make clean should ideally just call the clean target of the test-suite makefile
or specifically the copy in _build
Since that is known to work
Maxime Dénès said:
Is there a precise description on the next steps written somewhere, in a very detailed way that could serve as a basis for estimating the resources needed?
There is not, anyways it is common knowledge by build experts that such an estimation is far from easy c.f. (again) https://signalsandthreads.com/build-systems/
I think what would help much more than documenting what are likely low-level steps, is to specify and document the use cases developers want from the build system
already Makefile.dune tries to do this, however we are having some trouble with the ongoing migration for the reasons already explained
Anyways many things people could help have been already detailed and so far we are not seeing a lot of improvement; similarly with other non-build domains. Such lists are written, I spend hours writing long mails, I never hear back.
So not something I look forward a lot to keep doing
Last updated: Jun 10 2023 at 06:31 UTC