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.
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.
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.
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`.
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.
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?
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).
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.
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}?
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.
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.
Greg, do you need feedback on this, maybe for 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.
I guess Slavek is better than me for checking on cmake... :-)
In the commits that I have pushed are solved:
KUser linked the
ldaplibrary. This probably is not needed. At the same time, presence of this library was not tested => this causes FTBFS in a clean build environment.Fixed problems with building lilo-config.
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-widgetsinstead of too generalwidgets.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.
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
Gitea is really a great tool :-)
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?
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.
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).
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.
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}?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.
@cethyel, please, did you test if everything was right in your builds?
Can BUILD_OK.txt file be deleted?
@SlavekB
Sure.
It was quite instructive, thanks man!
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!
1cded3f73bでマージされています。