#5 First bach of cmake files for tdeadmin convertion to cmake

Merged
SlavekB merged 16 commits from gg-tdeadmin-cmake into master 8 months ago
cethyel commented 9 months ago

Still some work to do, It’s not in part with the autotools yet.

The BUILD_OK.txt file gives info to what is building.

Some trouble with kuser, a shared library must be missing in the linkage step, lilo-config does not build…yet.

Still figuring out how to add proper headers detection in order to make a valid config.h.cmake file, at the moment It’s just a copy of my config.h generated by autoheader.

Once It build fine, have to look for images and icons, my scratching nose tells me that some aren’t processed and/or placed at the right place.

No options to pass to the compiler yet.

Still some work to do, It's not in part with the autotools yet. The BUILD_OK.txt file gives info to what is building. Some trouble with kuser, a shared library must be missing in the linkage step, lilo-config does not build...yet. Still figuring out how to add proper headers detection in order to make a valid config.h.cmake file, at the moment It's just a copy of my config.h generated by autoheader. Once It build fine, have to look for images and icons, my scratching nose tells me that some aren't processed and/or placed at the right place. No options to pass to the compiler yet.
cethyel added the
PR/wip
label 9 months ago
MicheleC commented 9 months ago
Owner

Greg, do you need feedback on this, maybe for lilo-config?

Greg, do you need feedback on this, maybe for lilo-config?
cethyel commented 9 months ago
Poster

On the overall, I’d love to have some comments and feedback. lilo-config is giving me hard time. something eludes me for building lilo-config.

On the overall, I'd love to have some comments and feedback. lilo-config is giving me hard time. something eludes me for building lilo-config.
MicheleC commented 9 months ago
Owner

I guess Slavek is better than me for checking on cmake… :-)

I guess Slavek is better than me for checking on cmake... :-)
SlavekB started working 9 months ago
SlavekB stopped working 9 months ago
1h 9min 26s
SlavekB commented 9 months ago
Owner

In the commits that I have pushed are solved:

  1. KUser linked the ldap library. This probably is not needed. At the same time, presence of this library was not tested => this causes FTBFS in a clean build environment.

  2. Fixed problems with building lilo-config.

In the commits that I have pushed are solved: 1. KUser linked the `ldap` library. This probably is not needed. At the same time, presence of this library was not tested => this causes FTBFS in a clean build environment. 2. Fixed problems with building lilo-config.
SlavekB commented 9 months ago
Owner

Note: Because the target names in CMake are common for the entire project, it is appropriate to create unique target names for auxiliary libraries - such as liloconfig-widgets instead of too general widgets.

Note: Because the target names in CMake are common for the entire project, it is appropriate to create unique target names for auxiliary libraries - such as `liloconfig-widgets` instead of too general `widgets`.
SlavekB started working 9 months ago
cethyel commented 9 months ago
Poster

I added ldap because on Slackware, kuser does link with this library. Does kuser work with ldap authentication? I don’t know. Anyway, thanks for the help, I haven’t touch tdeadmin since my last commit, I’ll give it an other try next week. Still, some perl scripts (knetworkconf backends) are missing, I’ve found how kde4 build them but I haven’t figure out how to pass “scriptsdir” to the scripts yet.

I added ldap because on Slackware, kuser does link with this library. Does kuser work with ldap authentication? I don't know. Anyway, thanks for the help, I haven't touch tdeadmin since my last commit, I'll give it an other try next week. Still, some perl scripts (knetworkconf backends) are missing, I've found how kde4 build them but I haven't figure out how to pass "scriptsdir" to the scripts yet.
SlavekB stopped working 9 months ago
1h 12min 21s
SlavekB commented 9 months ago
Owner

As you can see commit a few minutes ago, I just completed the knetworkconf backend file processing :)

You can test and update your BUILD_OK.txt

As you can see commit a few minutes ago, I just completed the knetworkconf backend file processing :) You can test and update your BUILD_OK.txt
MicheleC commented 9 months ago
Owner

Gitea is really a great tool :-)

Gitea is really a great tool :-)
cethyel commented 9 months ago
Poster

If everything is building, then It remains to add some prototype function detection to config.h.cmake in order to be on part with autotools(*)…and adding some compiler options.

(*) Do we need cmake to mimic autotools to the last bits?

If everything is building, then It remains to add some prototype function detection to config.h.cmake in order to be on part with autotools(*)...and adding some compiler options. (*) Do we need cmake to mimic autotools to the last bits?
MicheleC commented 9 months ago
Owner

IMO, the more we match the autotools options, the better. But not being a big expert of all this, Slavek’s comment would probably more appropriate.

IMO, the more we match the autotools options, the better. But not being a big expert of all this, Slavek's comment would probably more appropriate.
cethyel commented 9 months ago
Poster

I’m not sure a perfect copy of autotools is needed.

Few days ago I had a go to tdesudo. This software also needs a config.h but at the first glance I’d say It’s a copy of what have been done so far, with 2 dozens of header checks and preprocessor defines but the software actually need just a couple of headers that aren’t provided by (t)qt3 and tdelibs, not dozens.

You may even build tdeadmin without a config.h for most modules. I know that, I built everything else without a config.h, it came later when I couldn’t build kuser, I started to look what I was missing (learner at work here people).

I'm not sure a perfect copy of autotools is needed. Few days ago I had a go to tdesudo. This software also needs a config.h but at the first glance I'd say It's a copy of what have been done so far, with 2 dozens of header checks and preprocessor defines but the software actually need just a couple of headers that aren't provided by (t)qt3 and tdelibs, not dozens. You may even build tdeadmin without a config.h for most modules. I know that, I built everything else without a config.h, it came later when I couldn't build kuser, I started to look what I was missing (learner at work here people).
SlavekB started working 9 months ago
SlavekB stopped working 9 months ago
1h 19min 43s
SlavekB commented 9 months ago
Owner

We certainly do not want config.h to be as close as possible to the output of autotools. There are many tests in autotools, which are unnecessary for most projects and the resulting config.h therefore contains many definitions that are not used anywhere in the project.

Checking the necessary and unnecessary definitions and tests is usually the most demanding part of CMake conversion!

As you can see in the last commit, I removed the unused definitions from config.h.cmake, removed related tests of include files, and added some missing tests.

Let me say that we are close to completing CMake conversion.

We certainly do not want config.h to be as close as possible to the output of autotools. There are many tests in autotools, which are unnecessary for most projects and the resulting config.h therefore contains many definitions that are not used anywhere in the project. Checking the necessary and unnecessary definitions and tests is usually the most demanding part of CMake conversion! As you can see in the last commit, I removed the unused definitions from config.h.cmake, removed related tests of include files, and added some missing tests. Let me say that we are close to completing CMake conversion.
cethyel commented 9 months ago
Poster

I tought so as well, having figured it out with tdesudo, they must have copied and pasted without much thinking.

Can we keep this branch open for a full week? I will study it next week during my spare time.

Questions:

In ConfigureChecks.cmake, you’ve removed the headers check, why? From memory, we need some of them,do we have to take those headers for granted?

In config.h.cmake, you’ve set sys_stat, unistd, etc, to 1, removing the test to generate a config.h file with those to 1 or 0 accordingly to the result of the tests. Therefore why don’t we just set them right in the code, in the headers with includes? Most config.h should be gone that way, I guess.

In kuser/CMakeLists.txt, How did you know to change from ‘crypt’ to “${CRYPT_LIBRARIES}” for instance? I did see later on, some examples with crypt in other packages but Is there a list somewhere with ${FOO_LIBRARIES}?

I tought so as well, having figured it out with tdesudo, they must have copied and pasted without much thinking. Can we keep this branch open for a full week? I will study it next week during my spare time. Questions: In ConfigureChecks.cmake, you've removed the headers check, why? From memory, we need some of them,do we have to take those headers for granted? In config.h.cmake, you've set sys_stat, unistd, etc, to 1, removing the test to generate a config.h file with those to 1 or 0 accordingly to the result of the tests. Therefore why don't we just set them right in the code, in the headers with includes? Most config.h should be gone that way, I guess. In kuser/CMakeLists.txt, How did you know to change from 'crypt' to "${CRYPT_LIBRARIES}" for instance? I did see later on, some examples with crypt in other packages but Is there a list somewhere with ${FOO_LIBRARIES}?
SlavekB commented 9 months ago
Owner

Tests for headers were not meant to “guarantee” the presence of the relevant files, but only to determine if the header file is present or not, because on some Unix systems may be different. Accordingly, the appropriate definition was set in config.h. However, most of these definitions that were previously used were not used in the code at all == the result of such tests is nowhere in use, tests were done unnecessarily. Therefore, such variables as well as tests can be removed.

As I mentioned above, some header files may be different on some Unix systems. Therefore, there are tests to verify which variant of the header file is currently present. So that the correct file can be used in the code - as defined in config.h. If a header that is not present was used in the code, the compilation would fail.

With some libraries, it’s similar to header files == can be different on different Unix systems. The crypt library is one of them. Testing of various library variants can be found in the original automake tests. Because the crypt library is also tested in tdelibs, I used the same test.

Tests for headers were not meant to "guarantee" the presence of the relevant files, but only to determine if the header file is present or not, because on some Unix systems may be different. Accordingly, the appropriate definition was set in config.h. However, most of these definitions that were previously used were not used in the code at all == the result of such tests is nowhere in use, tests were done unnecessarily. Therefore, such variables as well as tests can be removed. As I mentioned above, some header files may be different on some Unix systems. Therefore, there are tests to verify which variant of the header file is currently present. So that the correct file can be used in the code - as defined in config.h. If a header that is not present was used in the code, the compilation would fail. With some libraries, it's similar to header files == can be different on different Unix systems. The crypt library is one of them. Testing of various library variants can be found in the original automake tests. Because the crypt library is also tested in tdelibs, I used the same test.
SlavekB commented 8 months ago
Owner

@cethyel, please, did you test if everything was right in your builds?
Can BUILD_OK.txt file be deleted?

@cethyel, please, did you test if everything was right in your builds?<br/>Can BUILD_OK.txt file be deleted?
cethyel commented 8 months ago
Poster

@SlavekB

Can BUILD_OK.txt file be deleted?

Sure.

It was quite instructive, thanks man!

@SlavekB >Can BUILD_OK.txt file be deleted? Sure. It was quite instructive, thanks man!
SlavekB removed the
PR/wip
label 8 months ago
SlavekB commented 8 months ago
Owner

Rebased to current HEAD.
Merged and pushed upstream.

I leave the branch here, later you do the removal yourself.

Thank you for your good work!

Rebased to current HEAD. <br/>Merged and pushed upstream. I leave the branch here, later you do the removal yourself. Thank you for your good work!
SlavekB added this to the R14.0.6 release milestone 8 months ago
The pull request has been merged.
Sign in to join this conversation.
Loading…
Cancel
Save
There is no content yet.