Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problems for INCLUDE( ilcsoft_default_settings ) in CMakeLists.txt #4

Open
gridge opened this issue Apr 22, 2021 · 2 comments
Open

Comments

@gridge
Copy link

gridge commented Apr 22, 2021

When creating a CMakeLists.txt file to compile a few pulled packages together, the existing line

INCLUDE( ilcsoft_default_settings )

in this CMakeLists.txt file gives an error of duplicate unistall target defined.
I'm quite confused since it seems that in the various included files there's already a protection against that, but does not seem to be working.

To reproduce the problem the easiest is to pull:

git clone --recursive https://github.com/spg-berkeleylab/LBLMuC-SiDigiDev

and compile il following the instructions in the README.md.

@pandreetto
Copy link

As far as I can see the instruction "ADD_SUBDIRECTORY" is not the correct way for dealing with sub-packages.
In the framework there's a component (PandoraPFANew) that is composed of different sub-packages. The cmake file for that component uses the macro ExternalProject
I've never used such a macro, but it worths investigating its behaviour, it could be useful for other purposes.

It's not possible to remove the INCLUDE from the CMakeLists.txt, without that instruction the build (stand-alone) fails.
A possible work-around could be defining an OPTION, for example "-Dstandalone=TRUE", that disable the include if necessary.

@gridge
Copy link
Author

gridge commented Apr 27, 2021

Hi @pandreetto ,
I know of the ExternalProject and I've always found of very limited utility... in this case if I move to ExternalProject all the configuration step of each package happens in the build step of the "overall" repository, which is pretty annoying, and dependencies are gone.

With the add_subdirectory, I have them all nicely together and I can configure/build them all from the main package, which makes the development so much easier.

In any case, I agree we should not comment out that line of code of course and I'll simply make a new branch just for the PR without that comment every time for now. I'll see if I can find a better solution at some point.
(I would think the development of changes in these packages from the container is a pretty common use-case.. I'm quite surprised we're the only ones finding this problematic..)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants