#1572 $MAKE_FLAGS mechanism broken
Metadata
| Property | Value |
|---|---|
| Reported by | Rene Milk (rene.milk@uni-muenster.de) |
| Reported at | Feb 19, 2015 08:52 |
| Type | Bug Report |
| Version | Git (pre2.4) [cmake] |
| Operating System | Unspecified / All |
| Last edited by | Christian Engwer (christi@conan.iwr.uni-heidelberg.de) |
| Last edited at | Feb 25, 2015 15:59 |
| Closed by | Christian Engwer (christi@conan.iwr.uni-heidelberg.de) |
| Closed at | Feb 25, 2015 15:59 |
| Closed in version | Unknown |
| Resolution | Fixed |
| Comment |
Description
Having MAKE_FLAGS="-j4" in my opts file results in dunecontrol aborting trying to call "cmake --build . -j4", because "-j4" is ofc no valid argument to pass there.
- Is there currently any way to achieve what MAKE_FLAGS did when dunecontrol just called make directly?
- There should probably be some change in handling MAKE_FLAGS now
Activity
I will revert the commit that introduced all these problem as it is really annoying me.
I cannot even use dunecontrol all anymore:
----- using default flags $CONFIGURE_FLAGS from /home/mblatt/src/dune/opts/grids.opts ----- --- going to build dune-common dune-geometry dune-grid dune-alugrid --- --- calling all for dune-common --- --- calling vcsetup for dune-common --- --- calling autogen for dune-common --- Skipping dune-autogen because of CMake --- calling configure for dune-common --- ----- using default flags $CONFIGURE_FLAGS from /home/mblatt/src/dune/opts/grids.opts ----- CC=gcc CXXFLAGS=" -O0 -g" CFLAGS="-O0 -g" cmake -DCMAKE_MODULE_PATH="" -DUSE_MPI=ON -DCMAKE_INSTALL_PREFIX=/home/mblatt/dune_install "/home/mblatt/src/dune/current/dune-common" -- I could not find the latex2html command. -- Performing tests specific to dune-common from file /home/mblatt/src/dune/current/dune-common/cmake/modules/DuneCommonMacros.cmake. -- A library with BLAS API found. -- A library with LAPACK API found. -- Using scripts from /home/mblatt/src/dune/current/dune-common/cmake/scripts for creating doxygen stuff. -- using /home/mblatt/src/dune/current/dune-common/doc/doxygen/Doxystyle to create doxystyle file -- Not adding custom target for config.h generation
-- The following OPTIONAL packages have been found:
- Doxygen
- PkgConfig
- BLAS
- LAPACK
- GMP
- Inkscape
- MPI
- Threads
-- The following OPTIONAL packages have not been found:
- LATEX
- UnixCommands
-- Configuring done -- Generating done CMake Warning: Manually-specified variables were not used by the project:
USE_MPI- Doxygen
- PkgConfig
- BLAS
- LAPACK
- GMP
- Inkscape
- MPI
- Threads
-- The following OPTIONAL packages have not been found:
- LATEX
- UnixCommands
-- Configuring done -- Generating done CMake Warning: Manually-specified variables were not used by the project:
USE_MPI-- Build files have been written to: /home/mblatt/src/dune/current/dune-common/build-grids --- calling make for dune-common --- ----- using default flags $MAKE_FLAGS from /home/mblatt/src/dune/opts/grids.opts ----- build directory: build-grids cmake --build . all Unknown argument all Usage: cmake --build
[options] [-- [native-options]] Options: = Project binary directory to be built. --target = Build instead of default targets. --config = For multi-configuration tools, choose . --clean-first = Build target 'clean' first, then build. (To clean only, use --target 'clean'.) --use-stderr = Don't merge stdout/stderr. -- = Pass remaining options to the native tool. --- Failed to build dune-common --- Terminating dunecontrol due to previous errors!Please activate ninja in a feature branch!
There is a proposed solution feature/FS1572-make-parameters-broken.
Stating from the commit message:
[dunecontrol] add a new target build to invoke "cmake --build" We add a new target build, which will call cmake --build. calling make will always try to use make and will fail for other build systems. In case of build we prepend '--' to the command line parameters to separate cmake and build parameters, iff the user didn't alrready do so. This means the assume that the user generally want to pass parameters to the build command and not to cmake itself-
Should we switch "all" to "autogen : configure : build" ?
This would ease the use with other build systems and would presumably not change anything, as we fall back to make on autotools and cmake users are now able to call make, when they want to use additional parameters.
Also, I would not mind moving the mechanism that is now implemented in build into the make command... as Markus was afraid concerning compatibility I decided that the new command would be the safest path.
We do hate our users, don't we?
Do we really need a new target for this? I cannot see why. For me dunecontrol should be usable in the same way as before. It should not matter what kind of build system is used underneath.
Wouldn't it be possible to use make instead of build and simply translate targets in the CMake case. Just like Christoph proposed.
BTW: We might need to call ctest instead of cmake during make check.
I don't think we should support adding targets to dunecontrol in the first place. Instead, we can use bexec "make target" and we have all corner-cases included. I don't want to pipe that through dunecontrol. And adjusting "check" to "test" is even worse. There is a difference between the build systems and these are golden bridges, that are not worth the effort. We introduce complexity and probably bugs, for a limited benefit.
-
Sorry Markus, but what do you want? Either we switch to cmake, or we stay with make. Introducing magic to translate make target into cmake options is just error prone and imo a nightmare. I would not have suggested to add the build command, if you hadn't insisted on keeping everything the old way.
We can easily add the same simple check that I introduced in the build command into the make command. In this case you can call
dunecontrol make -j4 -i test and this will be translated into cmake --build . -- -j4 -i test which again is translated into make -j4 check iff you are using make to build your project.
If you are using something else, e.g. ninja, you get
ninja -j4 -i test which would bail out, as ninja doesn't know the option -i
Sorry, if I was not clear.
Basically I do not want to care about what buildsystem and/or what cmake backend is used underneath and in any case use "dunecontrol all" or "dunecontrol make ". If have done this for years and building new synapses gets painfuller the older you get ;) For me there is no need of a dunecontrol build mode but of course it does not hurt, too. BTW: I don't use any fancy options besides -j4 and I am aware that this might be make specific.
I have just tested your branch
- "dunecontrol all" results in building with "cmake --build . --"
- "dunecontrol make all" results in building with "make all". At least for me this is a surprise and I assume there are others that share this opinion and might (in the best case) file a bugreport that dunecontrol is broken for ninja or whatever.
My only aim is that dunecontrol detects that cmake is used and translates "dunecontrol make" to cmake --build . --" to make sure this works regardless of the backend.
