CLN-list

Download

cln-list@ginac.de

December 2020

4 participants
2 discussions

CMakeLists.txt: Improving GiNaC/CLN (& ease of) integration?
by Xunie 01 Feb '21

01 Feb '21

Hiya, fine folks, 🤠 I'm trying to integrate GiNaC into my CMake-based project and I'm having some difficulty setting up the build. I was hoping you all could point me in the right direction. My questions: #1: How do you build GiNaC/CLN when working on your own projects? Am I the only one that uses CMake? #2: Could we make the CMake build system (and the integration of GiNaC) slightly easier to work with? >From a quick glance, CLN and GiNaC seem tightly interwoven. Am I correct in assuming there's a reason CLN doesn't have a CMakeLists.txt? Or is this mainly historical and can I safely start adding a CMake build? -------------------------- # My problem: My general git/CMake/C++ workflow consists of integrating every dependency I have as a git submodule under a common directory and point my CMakeLists.txt at each dependency. This has worked for me so far and seems like a reasonably clean way of dealing with dependencies on platforms where they might not be immediately available (i.e. MINGW). GiNaC's CMake build searches via a module ('cmake/modules/FindCLN.cmake') for a fully built CLN. This is simply not possible during the configuration step of my CMake build since at that point, CLN isn't even fully configured yet! Anyone have any idea how best to integrate GiNaC and CLN? How do YOU do it? Are there any big projects using GiNaC that I can look at? # How do we improve the CMake building experience of GiNaC & CLN? I'm open to suggestions, but I think merely adding a CMakeLists.txt to CLN should enable a better GiNaC build experience without having to modify GiNaC itself! Maybe modify that module just a tad bit but that oughta do it. If so desired, CLN's CMake build could just be made a proxy for the autotools build. I've also noticed that CLN's autogen.sh downloads some things via HTTPS from some git repo. This could immediately be looked at during this process. # The task (I estimate) there's 1202 source files in CLN as of writing so this is quite a task. I even bumped into source files specific to HP/PA ("Hewlett Packard Precision Architecture") which preceded Itanium which itself will be Discontinued in 2021! This makes CLN quite the antique! None the worse for wear I guess. ;-) Unless I'm mistaken, I doubt anyone still uses HP/PA in production in this day and age. (Ahh, they don't make 'em like they used to...) All in all: Should I or anyone else start working on CLN's CMakeLists.txt? Kind Regards & Happy Holidays, Xunie

4 12

Fw: Re: CMakeLists.txt: Improving GiNaC/CLN (& ease of) integration?
by Xunie 29 Dec '20

29 Dec '20

Hey Bruno, (Sorry you got this e-mail twice, I sent the first one to you directly instead of the mailing list!) On Monday, December 28, 2020 4:00 AM, Bruno Haible <bruno(a)clisp.org> wrote: > It seems that using a CMake 'ExternalProject' would allow you to use CLN's > configure-based build system from CMake [1]. No? About 2 years ago, I tried to integrate GiNaC into the same project I am trying to integrate it into right now. I failed and gave up. I've spent the last week wrestling with ExternalProject and looking at that exact same stackexchange answer trying to get it working this time. It was a highly frustrating experience. ExternalProject is and always will be a hack to incorporate non-CMake projects into CMake. > It is usually a waste of time to maintain two build systems (for CLN, in this > case) in parallel, when one is sufficient. Maybe, maybe not. GiNaC already has CMake support, why not CLN? Considering the (apparent) complexity and vintage of CLN, I certainly think maintaining a modern CMake build is not wasted effort. CMake has got to be the most popular C++ build system right now. I can't find any numbers on it, but seeing CMake-less projects is an exceptional rarity for me. But that's just my (n=1) experience. In the interest of making GiNaC/CLN easier to use, full CMake build support will improve user-experience. That's just my two cents, though. Personally I'm gonna build on Alexey's cmake branch, try to fix some CMP0002 warnings/errors I ran into and failing that, doing what he does and build CLN in-source inside GiNaC's source tree. It certainly beats wrangling autotools on my two platforms. I am trying my best to make my project testable and this includes sanity-testing my dependencies. God knows how much time and effort I'd have to invest trying to FULLY integrate CLN's autotools tests/exams into my CMake build. THAT is wasted effort. But hey, Alexey already did incorporate the tests it seems. :) If he's been using CMake to build CLN for a decade now, I have to ask: why isn't it incorporated already? All in all, a 2nd CMake build is not at all wasted effort if you ask me. Kind Regards, Xunie

1 0