[Citadel Development] (null)
With CMake, all the dependencies are listed right there in CMakeLists.txt, so someone creating a port for their OS of choice can damn near copy-paste the dependencies into the file that describes the port in whatever ports/pkg system is in use. I've never seen CMake be an issue for compatibility across multiple systems, and since it's a ready-made package for basically every OS, build time for CMake should be a non-issue. Even those who build everything from ports wouldn't have much issue because CMake is already used for much of the other infrastructure apps already in use.
[Citadel Development] Re: Build System
Thu Aug 10 2023 15:02:19 EDT from IGnatius T Foobar Subject: Re: Build System CPPFLAGS is not used anywhere because there is no C++ anywhere in the system. CPPFLAGS are not related to c++ but are preprocessor flags (like: -I/opt/something/include). c++ compiler options would be CXXFLAGS. as for creating a patch, i would but if you wanna switch to cmake anyway it might not be necessary anymore. a word of caution though regarding cmake: in many cases the problem with cmake is cmake itself because it has quite hefty compiler requirements. ironically often much more hefty than the actual program it's supposed to prepare. in case if citadel that would be such a case. so if compatibility is important to you, cmake is not a good choice.
[Citadel Development] (null)
I already did the account creation thingy. Thu Aug 10 2023 18:46:53 EDT from IGnatius T Foobar Absolutely! Just go to https://code.citadel.org and create an account. You will need to use your @uncensored.citadel.org address, at least initially. I'll approve it in short order.
[Citadel Development] (null)
Absolutely! Just go to https://code.citadel.org and create an account. You will need to use your @uncensored.citadel.org address, at least initially. I'll approve it in short order.
[Citadel Development] (null)
Can I pwease be granted access to the lab of git? I promise not to hock up too many hairballs.
[Citadel Development] (null)
It is nice and clean. Additionally, it makes creating a FreeBSD port dead-simple: https://github.com/freebsd/freebsd-ports/blob/main/security/diffcode/Makefile The line that causes it to be built and packaged purrfectly for insertion into the FreeBSD Ports repos is line 12, "USES = cmake". No other magic is needed. A lot of Makefile-based projects have moar complercated ports because the locations of the output files varies widely. Thu Aug 10 2023 15:19:38 EDT from IGnatius T Foobar If it were up to me, the entire build system would be using CMake. That does look nice and clean. My objective wasn't to stop using Make, but to stop using the GNU Autotools stuff. Those tools are built to handle all sorts of obscure edge cases that don't exist anymore. There just isn't that much variation in our target platforms anymore, so a few simple tests are all we need. As long as it builds on BSD and Linux, I'm fine with it; we no longer have to check for oddball systems with oddball libraries because no one is running Citadel on those systems anymore (and we don't have enough developer time to support them anyway). I probably reinvented a wheel somewhere ... but it was a very basic, very simple wheel. All of the usual criticisms of Richard Marx Stallman are included herein by reference.
[Citadel Development] (null)
>If it were up to me, the entire build system would be using CMake. That does look nice and clean. My objective wasn't to stop using Make, but to stop using the GNU Autotools stuff. Those tools are built to handle all sorts of obscure edge cases that don't exist anymore. There just isn't that much variation in our target platforms anymore, so a few simple tests are all we need. As long as it builds on BSD and Linux, I'm fine with it; we no longer have to check for oddball systems with oddball libraries because no one is running Citadel on those systems anymore (and we don't have enough developer time to support them anyway). I probably reinvented a wheel somewhere ... but it was a very basic, very simple wheel. All of the usual criticisms of Richard Marx Stallman are included herein by reference.
[Citadel Development] (null)
More notes on the database abstraction layer: I did point out that the API isn't totally frozen :) For database cursors, we were keeping cursor variables around per-thread-per-table, which requires putting Berkeley DB specific stuff in server/threads.h , and that's got to go. Therefore I am changing the API so that cdb_rewind() returns a cursor, and cdb_next_item() must be passed that cursor with every call. As always, the caller is expected to keep reading until the end, at which point the cursor is de-allocated by the backend. The data type of the cursor is `void *` and the backend is expected to cast it to its own native type.
[Citadel Development] (null)
If it were up to me, the entire build system would be using CMake. That's what I use in all my projects: https://github.com/LadySerenaKitty/klaculate https://gitlab.com/LadySerenaKitty/diffcode https://gitlab.com/LadySerenaKitty/hexcode https://gitlab.com/LadySerenaKitty/rotate
[Citadel Development] Re: Build System
UFarx: your suggestions for the build system are most welcome. I don't suppose we could ask you to submit a patch? We have a GitLab instance at [ https://code.citadel.org ] which accepts merge requests to the repository. (You'll need to sign up for it using uf...@uncensored.citadel.org as your email address, since it only accepts citadel.org signups to prevent noise from the outside.) I believe we do use CFLAGS and LDFLAGS in at least some of the builds. We're in the process of moving away from the GNU Autotools, as you might have noticed. Citadel Server, the text client, and WebCit-NG are using our own build system, while WebCit Classic and libcitadel are still on the GNU tools. CPPFLAGS is not used anywhere because there is no C++ anywhere in the system.
