Opened 14 years ago
Closed 13 years ago
#434 closed enhancement (done)
Phase out Autotools in favor of CMAKE
| Reported by: | Alpar Juttner | Owned by: | Alpar Juttner |
|---|---|---|---|
| Priority: | blocker | Milestone: | LEMON 1.3 release |
| Component: | build system | Version: | hg main |
| Keywords: | Cc: | ||
| Revision id: |
Description (last modified by )
The most important missing feature of the CMAKE based build environment is the generation of the release tarball. The good thing is that cmake needs basically no generated files (like the configure script and the Makefile.in files in case of Autotools). Still, it should generate
cmake/version.cmakeand- the HTML documentation
and add them to the release tarbal.
Change History (7)
comment:1 Changed 14 years ago by
| Owner: | changed from Akos Ladanyi to Alpar Juttner |
|---|
comment:2 Changed 14 years ago by
| Description: | modified (diff) |
|---|---|
| Summary: | CMAKE based release tarball creation → Phase out Autotools in favor of CMAKE |
comment:3 Changed 14 years ago by
comment:4 follow-up: 5 Changed 14 years ago by
I find the cmake-based testing a bit incomfortable. The summary correctly indicates which tests failed (if any), but no other information is shown. E.g.:
The following tests FAILED:
29 - min_mean_cycle_test (OTHER_FAULT)
Errors while running CTest
The console output of the test cases are redirected to the file <builddir>/Testing/Temporary/LastTest.log. Actually, it does not seem to be an obvious place to check if someone is looking for the console output. (I found it only by recursively searching for the last modified files in the build directory. :))
Is there an easier/better way for obtaining the console output of failed test cases?
comment:5 Changed 14 years ago by
Replying to kpeter:
Is there an easier/better way for obtaining the console output of failed test cases?
I would run the failed test by hand:
$ ./test/min_mean_cycle_test
It is indeed one step more complicated than it was with autotools, but I personally can live with it, so gave up trying to find any better solution.
comment:7 Changed 13 years ago by
| Resolution: | → done |
|---|---|
| Status: | new → closed |


I pushed three changesets to the repo:
cmake/version.cmakeexists in the source tree (i.e. when compiling a release tarball) the version string comes from there. ElseLEMON_VERSIONshell environment is defined, it will be used. ElseLATESTTAG+DIST-HASH, whereLATESTTAGis the latest tagged ancestor revision, ortrunkif there is no tagged ancestorDISTis the length of the longest path betweenLATESTTAGand the current revision in the history graph.HASHis the short hash id of the current reviosion.hg-tip.make disttarget. It creates the release tarball with and without doc and the documentation alone, both intar.gzand is zip format in all case. In addition it makes the documentation generation more clever.doc/htmldirectory (i.e. we compile from a release tarball with doc), and there is nodoc/htmlin the build dir, the pre-generated doc will be copied to the latter place, thereforemake installwill install it.make htmlis run, then it will overwrite the original (only in the build dir, of course), thusmake installwill install the new version.Now, I believe all the features of the autotool build environment are also provided by the cmake version.
I still keep this ticket open for some time. Please check the cmake config and tarball generation in all the possible use-case scenarios and the available platforms and report any problem you may encounter.