[CLN-list] CMakeLists.txt: Improving GiNaC/CLN (& ease of) integration?

Xunie xunie at protonmail.com
Tue Dec 29 11:28:49 CET 2020


Hey Alexey.

Thanks! Your suggestion of building CLN inside GiNaC's source directory. It seems to work fine. BUT I have some beef with it.

1) I hear that in-source building is not recommended with CMake.
I'm not experienced enough with CMake to comment on this. So maybe I'm cargo-culting/parroting right now. I'll yield to your expertise if you say that building dependencies inside source directories is established/good CMake practice. But this seems like an old/outdated way of doing things with CMake.

Anyone, please tell me if I'm right or wrong about that.

I'll try and see if I can come up with a better solution.


2) The CMake code seems to be of a certain 'vintage' and doesn't play nice with merely using add_subdirectory( cln ) followed by add_subdirectory( ginac ). When doing this, there's a lot of CMake Policy CMP0002 errors.

I set up test case demonstrating it here: https://github.com/Xunie/ginac-problem/

Try it yourself:
# setup project
git clone https://github.com/Xunie/ginac-problem.git
cd ginac-problem
git submodule init
git submodule update
cd ..

# configure the build
mkdir ginac-problem-build
cd ginac-problem-build
cmake ../ginac-problem

When add_subdirectory( git-submodules/ginac ) is removed, the CMP0002 issues with *CLN* go away!??!
Either I'm using CMake wrong or there's a problem with either GiNaC or CLN's CMake build that needs to be fixed.
Which one is it?


The following error repeated for different targets is what I get:
CMake Error at git-submodules/cln/src/CMakeLists.txt:952 (add_library):
  add_library cannot create target "cln" because another target with the same
  name already exists.  The existing target is a shared library created in
  source directory
  "/home/xunie/Desktop/tmp/PROJECT/git-submodules/cln/src".  See
  documentation for policy CMP0002 for more details.

I have no idea why CMP0002 is violated. How can add_library() name-clash with itself?!
Short of setting CMP0002 policy to 'old' behavior, I have no fix yet.
Is this even a problem with CLN and not GiNaC? I have no idea.


On Monday, December 28, 2020 6:58 AM, Alexey Sheplyakov <asheplyakov at yandex.ru> wrote:
> I think it's better to reuse the existing one.
Oh definitely, I wasn't aware of your efforts because it wasn't in the official repo.
(Another reason to integrate it?)

At the risk of stepping on toes; If that CMP0002 bug/feature is fixed, I see no reason to not integrate it into the official repo.
But hey, it ain't my project and I'll leave it to you seasoned veterans to decide. :P

Kind Regards,
Xunie


More information about the CLN-list mailing list