Built binaries contain reference to source directory

[mueslo]

Description

I would like to build a package of triqs for my Linux distribution of choice. However, I noticed that upon compilation, TRIQS hardcodes a lot of build and source directory paths into the built binaries, and files etc. This is not good practice and should be fixed.

Steps to Reproduce

1. Build triqs package with:

cmake . -DCMAKE_INSTALL_PREFIX=$pkgdir/usr -DPYTHON_INTERPRETER:FILEPATH=python2
make
make install

2. grep -r "$builddir" $builddir

Expected behavior: No results.

Actual behavior: Results for
/path/to/build/triqs/usr/bin/triqs++
/path/to/build/triqs/usr/share/cmake/Modules/run_test.cmake
/path/to/build/triqs/usr/share/cmake/Modules/FindTriqsTest.cmake
/path/to/build/triqs/usr/share/cpp2pyvars.sh
/path/to/build/triqs/usr/share/triqsvars.sh
/path/to/build/triqs/usr/lib/cmake/triqs/triqs-targets.cmake
/path/to/build/triqs/usr/lib/cmake/triqs/TRIQSConfig.cmake
/path/to/build/triqs/usr/lib/cmake/cpp2py/Cpp2PyConfig.cmake
/path/to/build/triqs/usr/lib/cmake/cpp2py/cpp2py-targets.cmake
/path/to/build/triqs/usr/lib/libtriqs.so.2.2
/path/to/build/triqs/usr/lib/python2.7/site-packages/pytriqs/magic.py
/path/to/build/triqs/usr/lib/python2.7/site-packages/pytriqs/gf/meshes.so
/path/to/build/triqs/usr/lib/python2.7/site-packages/pytriqs/gf/gf_fnt.so
/path/to/build/triqs/usr/lib/python2.7/site-packages/pytriqs/gf/wrapped_aux.so
/path/to/build/triqs/usr/lib/python2.7/site-packages/pytriqs/gf/gf_factories.so
/path/to/build/triqs/usr/lib/python2.7/site-packages/pytriqs/operators/util/extractors.so
/path/to/build/triqs/usr/lib/python2.7/site-packages/pytriqs/operators/operators.so
/path/to/build/triqs/usr/lib/python2.7/site-packages/pytriqs/atom_diag/atom_diag.so
/path/to/build/triqs/usr/lib/python2.7/site-packages/pytriqs/arrays/block_matrix.so
/path/to/build/triqs/usr/lib/python2.7/site-packages/pytriqs/lattice/lattice_tools.so
/path/to/build/triqs/usr/lib/python2.7/site-packages/pytriqs/statistics/histograms.so
/path/to/build/triqs/usr/lib/python2.7/site-packages/pytriqs/random_generator/random_generator.so

Furthermore, references to the python binary location are saved in:
$ grep -lr "/path/to/python/virtualenv/" $builddir
/path/to/build/triqs/usr/bin/triqs++
/path/to/build/triqs/usr/lib/cmake/cpp2py/Cpp2PyConfig.cmake
/path/to/build/triqs/usr/lib/python2.7/site-packages/cpp2py/libclang_config.py

Versions

2.2.1 release

[Wentzell]

Dear @mueslo,

We do not hardcode paths to the either the source directory or the build directory into any of the files
that are installed with TRIQS. We do however hardcode the actual install directory and paths to various dependencies into some of our files. This should not be a problem for packaging TRIQS however.
You can have a look at our anaconda package or at the Dockerfile for our debian package generation to see how we currently package TRIQS.

It seems further that you are building TRIQS directly in the source directory

cmake . -DCMAKE_INSTALL_PREFIX=$pkgdir/usr -DPYTHON_INTERPRETER:FILEPATH=python2
make
make install

This is bad practice and should not be done. Please follow the steps on our installation page, which outline how to build TRIQS with a separate source and build directory.

[mueslo]

It seems further that you are building TRIQS directly in the source directory

True, but beside the point.

We do not hardcode paths to the either the source directory or the build directory into any of the files that are installed with TRIQS.

This is evidently wrong.

Even if I change the building steps to

cmake . -DCMAKE_INSTALL_PREFIX=/usr -DPYTHON_INTERPRETER:FILEPATH=python2
make
DESTDIR=$pkgdir make install

The resulting files still contain references to the source directory headers and source files:

$ grep -lr "$srcdir" ~/.cache/pikaur/build/triqs/pkg/triqs/
/path/to/build/triqs/usr/lib/libtriqs.so.2.2
/path/to/build/triqs/usr/lib/python2.7/site-packages/pytriqs/gf/meshes.so
/path/to/build/triqs/usr/lib/python2.7/site-packages/pytriqs/gf/gf_fnt.so
/path/to/build/triqs/usr/lib/python2.7/site-packages/pytriqs/gf/wrapped_aux.so
/path/to/build/triqs/usr/lib/python2.7/site-packages/pytriqs/gf/gf_factories.so
/path/to/build/triqs/usr/lib/python2.7/site-packages/pytriqs/operators/util/extractors.so
/path/to/build/triqs/usr/lib/python2.7/site-packages/pytriqs/operators/operators.so
/path/to/build/triqs/usr/lib/python2.7/site-packages/pytriqs/atom_diag/atom_diag.so
/path/to/build/triqs/usr/lib/python2.7/site-packages/pytriqs/arrays/block_matrix.so
/path/to/build/triqs/usr/lib/python2.7/site-packages/pytriqs/lattice/lattice_tools.so
/path/to/build/triqs/usr/lib/python2.7/site-packages/pytriqs/statistics/histograms.so
/path/to/build/triqs/usr/lib/python2.7/site-packages/pytriqs/random_generator/random_generator.so

(With these build steps, there is no longer any reference to the build directory, so that that part of my initial report is wrong)

[Regarding CMAKE_INSTALL_PREFIX, changing this should ideally not result in a different build (i.e. require recompilation). All it should do is change the make install installation target. But I guess it is necessary to allow direct running from a user directory without systemwide installation or static linking.]

[Wentzell]

Dear @mueslo,

You are indeed correct!
I had a look at the preprocessed source files that are compiled into the binaries you mention, and we are using the __FILE__ preprocessor macro in various error messages (c.f. triqs/utility/exceptions.hpp:31) to provide information on the file and line-number where the error occurred.

The proper course of action would be to strip the source directory from these File-Paths.
I will keep this issue open as we have other priorities at the moment.

Regarding the CMAKE_INSTALL_PREFIX, we are using this in files such as triqsvars.sh.in which allows the user to load a given TRIQS installation into their environment. I do not see a nice way around this hard-coded path however.

[parcollet]

c++ sourceloc = std::string {fs::canonical(sloc)};

fs = std::filesystem

[parcollet]

// includer of filesystem for clang compiled against gcc < 8

#if __has_include(<filesystem>)
#include <filesystem>
namespace fs = std::filesystem;
#else
#include <experimental/filesystem>
namespace fs = std::experimental::filesystem;
#endif```

[parcollet]

@Wentzell To solve the link pb with your remove source_root solution