It converted to Autotools configure flags to CMake flags.

Elias Pipping authored 9 years ago and Christoph Grüninger committed 9 years ago

On FreeBSD, e.g., bash is installed to /usr/local

Similar to update, status, svn, git, exec, and bexec skip the check
whether the versions for dependencies are fulfilled.

These are the *.la files below dune and the primary module library
lib<module name without dashes>.la.

This reverts commit 21dbaefe.
Thus if libtool libs are found, then we abort again.
Please do not merge to the release.

Actually, having these files lying around does not hurt us.
In addition there are downstream modules that especially create
these for compatibility reasons with autotools. For these
reconfiguring a module using dunecontrol currently aborts with an error

Therefore this commit resorts to just issuing a warning and proceeding
with the compilation instead of aborting with an error.

Claus-Justus Heine authored 9 years ago and Christoph Grüninger committed 9 years ago

Although GNU find may allow to omit the directory
argument, an ordinary (e.g. BSD) find does not.

if the user has for some reason old la files from the autotools era,
these can lead to very subtle and hard to understand errors. We now
check for old la files and bail out in case some are found.

Previously, the command vcsetup, which is executed on command 'all',  was not
listed on the help screen.

This reverts commit 9f9bc5c0.

see FS#1576

We fix the option handling when calling "cmake --build", by prepending '--' to the command
line parameters, in order to separate cmake and build parameters, iff the user didn't alrready do
it himself so. Note that this means we assume that the users generally want to pass
parameters to the build command and not to cmake itself.

This reverts commit eb045a4d.

As it severly breaks using the make build system. See
https://dune-project.org/flyspray/index.php?do=details&task_id=1572

this makes new automake versions work like old automake versions. Some
of my projects used to compile objects in subdirs from parent directories.
New automake versions don't allow this. We don't want to atopt our
projects to changes in automake and make the transition to cmake... so
keep the old behaviour, by adding this option.

Previously this was only set if run_default_configure was executed
before. Ergo dunecontrol make did try to use cmake even if USE_CMAKE=no
was set. This fixes flyspray 1560.
https://dune-project.org/flyspray/index.php?do=details&task_id=1560

It sets LOCAL_USE_CMAKE for the current module depending on USE_CMAKE
and whether there actually is CMake support for this module.
This will make it more easy to use the same check in all run_*
directives.

Previously we did not catch patterns at the start of the line.
Seems like sed cannot handle [ ^] as the meaning of
^ is the not operator here and not the line beginning.

Unfortunately environment variables with these names are not honored by CMake's
FindMPI. Therefore this commit translates them to MPI_{C,CXX}_COMPILER and
adds them to CMAKE_FLAGS before calling cmake.

When deciding which variable to put before cmake as environment variables
our sed pattern did not check for the beginning of a word or line. Therefore
MPICC=bla would be converted to CC=bla.
With this commit we make sure that there is eihter a beginning of a line or
a whitespace before the variable.

This enables ninja-build and other build systems to be called
correctly.
Targets can be passed by adding "--target <targetname>

The warning was spilled out for every module for every command,
even for update.
The build directory is announced by CMake's configure anyway.
Now it is printed for make, too.

CMAKE can now be set in the shell or the opts file, if both are set
the shell has higher priority.
This feature was dropped in …aef001c21e3a9 to fix FS#1518.

The only case we do not want to use the build-dir is
when explicitly autotools are used.

CMAKE is nom handled similar to MAKE.
CMAKE is no longer evaluated in the opts file as this would overwrite
a CMAKE set by the dunecontrol call.
This fixes FS#1518.

Once CMake will be default, people can deactivate it.

dunecontrol is capable of doing out of source builds, that are
not nested within the source directory by giving an absolute path
to the --builddir option. Unfortuantely, this (nice) feature was
not documented.

sadly the touchpad added some arbitrary "pwd; ", which slipped my
test, as I don't use cmake. Thanks to Andi Buhr for pointing this out.

up to now you could specify a BUILDDIR variable, which implied that modules were built in
$srdir/$BUILDDIR.
Imagine you have your dune modules in $HOME/Src. When you set BUILDDIR=build.g++
your dune-common module is built in $HOME/Src/dune-common/build.g++
Now you change BUILDDIR to an absolute path, e.g. BUILDDIR=$HOME/Build.g++
With the latest change dunecontrol will now build dune-common in
$HOME/Build.g++/dune-common/

Thanks to Angar for bugging me :-)

Bård Skaflestad authored 11 years ago and Christoph Grüninger committed 11 years ago

This commit implements support for using nested build directories of
the form

    (o) build/sequential/debug/cmake/clang
    (o) build/parallel/release/autotools/gcc

in addition to the separate build directory feature that already
existed.  This enables confining multiple build configurations to a
single subdirectory of each module's directory to avoid otherwise
littering the module directory.

Note: Using "mkdir -p" presumes a SUS v3 mkdir(1) utility.

The dune symlink was deprecated since 2009.

This completes the last patch by using $m for the module name. Finally,
installed modules are found correctly.

The check was whether $module_inst is yes, but what we actually want to check
is $INT_$module. This patch fixes this and forces configure to use pkg-config
for the installed module again. Only this allows us to extract custom libdirs.