Opened 15 years ago
Closed 15 years ago
#307 closed defect (fixed)
Two errors concerning make distclean
Reported by: | sschmidt | Owned by: | Christian Speckner |
---|---|---|---|
Priority: | P3 | Milestone: | v2.0.1 |
Component: | configure | Version: | 2.0.0 |
Severity: | minor | Keywords: | make distclean |
Cc: |
Description
Two errors concerning make distclean, they might be connected:
- make distclean fails when executed in a freshly checked out svn, eg.
svn co http://svn.hepforge.org/whizard/trunk . && autoreconf && ./configure FC=gfortran && make distclean
leads to
make[3]: Entering directory `/localscratch/sschmidt/whizard/temp2/src/omega/bin' Makefile:810: ../src/Makefile.depend_fortran: No such file or directory Makefile:811: ../src/Makefile.depend_ocaml: No such file or directory make[3]: *** No rule to make target `../src/Makefile.depend_ocaml'. Stop. make[3]: Leaving directory `/localscratch/sschmidt/whizard/temp2/src/omega/bin'
- If sourcedir and builddir are the same, consecutive execution of make && make distclean && make
svn co http://svn.hepforge.org/whizard/trunk . && autoreconf && ./configure FC=gfortran && make && make distclean && ./configure FC=gfortran && make
leads to an error
9 output files written: vamp.1 .. vamp.9 Transcript written on vamp.log. test -r vamppics.mp && mpost vamppics This is MetaPost, Version 0.641 (Web2C 7.5.4) (vamppics.mp ! I can't find file `feynmp'. l.2 input feynmp
in the second run of make. (The first one works)
Comparing the trunk after check out and after make distclean, I noticed that after make distclean share/doc/manual.tex is missing while there are some dirs withadditional files compared to the state immediately after checkout.
Change History (12)
comment:1 Changed 15 years ago by
comment:2 Changed 15 years ago by
Priority: | P3 → P2 |
---|---|
Severity: | normal → major |
TO, maybe you could have a look on this....
comment:3 Changed 15 years ago by
Owner: | changed from ALL to ohl |
---|
comment:4 Changed 15 years ago by
Owner: | changed from ohl to Christian Speckner |
---|
comment:5 Changed 15 years ago by
Status: | new → assigned |
---|
comment:6 Changed 15 years ago by
First half fixed in r2387. Second half will follow... after lunch :)
comment:8 Changed 15 years ago by
Resolution: | fixed |
---|---|
Status: | closed → reopened |
For me, both sets of commands now give errors different from the ones above. Will ask CS about it.
comment:9 Changed 15 years ago by
As requested by CS: the error messages:
1: for make distclean on fresh svn
make[2]: Entering directory `/localscratch/sschmidt/whizard/temp2/src/vamp' Making distclean in tests make[3]: Entering directory `/localscratch/sschmidt/whizard/temp2/src/vamp/tests' Makefile:761: Makefile.depend: No such file or directory make[3]: *** No rule to make target `f90.m4', needed by `tao_test.f90'. Stop. make[3]: Leaving directory `/localscratch/sschmidt/whizard/temp2/src/vamp/tests' make[2]: *** [distclean-recursive] Error 1
2: for make && make distclean && make
make[1]: Entering directory `/localscratch/sschmidt/whizard/temp/trunk/share' Making all in doc make[2]: Entering directory `/localscratch/sschmidt/whizard/temp/trunk/share/doc' make[2]: *** No rule to make target `manual.tex', needed by `all-am'. Stop. make[2]: Leaving directory `/localscratch/sschmidt/whizard/temp/trunk/share/doc' make[1]: *** [all-recursive] Error 1
comment:10 Changed 15 years ago by
The first issue can't be fixed in any reasonable way. The reason is the automagic generation of dependencies, leading to the following chain of events on a make (dist)clean
in a virgin tree from SVN:
- make tries to include Makefile.depend -> fails
- make tries to generate Makefile.depend -> requires tao_test.f90
- make tries to generate tao_test.f90 -> requires ../src/f90.m4
- because this is a virgin checkout and the
SUBDIRS
are preocesses in _reverse_ order onmake (dist)clean
, ../src/f90.m4 doesn't exist yet -> make fails with the above error message
However, this problem only affects _virgin checkouts_, once any makefile target different from (dist)clean has been processed, there is no "legal" way to get this error again (without deleting files manually). Therefore, I think the significant changes to the build systems necessary to avoid this are not worth the gain -> this part is "wontfix".
comment:12 Changed 15 years ago by
Priority: | P2 → P3 |
---|---|
Resolution: | → fixed |
Severity: | major → minor |
Status: | reopened → closed |
The second issue is fixed in r2393.
Forgot to mention: Tested with r2383, so not solved by #306