WIP:Conversion to the cmake building system. #46

Rem: 3 files to generate first with parameters provided by configure:

ntconfig.h
ntqmodules.h in the "include" folder
qconfig.cpp 🔼 removed limit 267 chars array length, must be checked! 🔼

check for:
Amarok's MySQL, HAVE_STRUCT_ST_MYSQL vs HAVE_STRUCT_MYSQL

Have a look at the Threading support.

I would suggest not to use the TDEMacros here at all: it will be tricky to make them work correctly without pre-installed tqt utils.

I would suggest not to use the TDEMacros here at all: it will be tricky to make them work correctly without pre-installed tqt utils.

It is clear that there is no right to use:

find_package( TQt )
find_package( TDE )

…but avoiding using TDEMacros as a whole doesn't seem like a good idea to me. Our macros makes writing CMake rules simply and clearly, so here I don't see as beneficial to throw this advantage and wrote basically the same rules in a less clear way.

I assume that there may be a need to solve parts like calling tqmoc (ie AUTOMOC) and others where is commonly already available tqtinterface, but I assume that not-use TDEMacros would be more inconvenience.

I would suggest not to use the TDEMacros here at all: it will be tricky to make them work correctly without pre-installed tqt utils.

I'm always open to suggestions (especially from you), but do you have something in mind that can be tricky to solve with the usual macros? Can you elaborate?

In general, I actively dislike leaking of the TDE-specific macros to external dependencies even those are maintained in TDE. IMHO it's a dirty practice, and the fact that they are still included as a submodules heavily mangles the commit history.

I'm always open to suggestions (especially from you), but do you have something in mind that can be tricky to solve with the usual macros? Can you elaborate?

To be specific, in case of tqt, it probably will create troubles with dependencies upon moc and uic, as those won't be avaliable during compile time. So at least you will have to avoid the tde_add_executable and tde_add_library macros for most of code base. As for moc/automoc support, it probably could be worked-around in some way, but the uic support (used in tools/) likely will have to be rewritten quite a lot.

Without those two I don't really see big benefits in dependencies upon the tde's cmake.

I first looked closely up to MOC. In TQt, I found the difference in using AUTOMOC.

In TDE use AUTOMOC performs processing matching *.h files, while in TQt, it is necessary to process the *.cpp files as such. In addition, header files are processed separately into moc_<header>.cpp. Yes, this will need to be solved. However, this does not seem to be a large obstacle that would mean to avoid using tde_add_executable and tde_add_library.

I get this error today (didn't have any yesterday):

CMake Error at TQtMacros.cmake:228 (list):
  list sub-command REMOVE_ITEM requires list to be present.
Call Stack (most recent call first):
  src/table/CMakeLists.txt:27 (tqt_automoc)


CMake Error at TQtMacros.cmake:228 (list):
  list sub-command REMOVE_ITEM requires list to be present.
Call Stack (most recent call first):
  src/widgets/CMakeLists.txt:88 (tqt_automoc)


CMake Error at TQtMacros.cmake:228 (list):
  list sub-command REMOVE_ITEM requires list to be present.
Call Stack (most recent call first):
  src/widgets/CMakeLists.txt:88 (tqt_automoc)


CMake Error at TQtMacros.cmake:228 (list):
  list sub-command REMOVE_ITEM requires list to be present.
Call Stack (most recent call first):
  src/widgets/CMakeLists.txt:88 (tqt_automoc)


CMake Error at TQtMacros.cmake:228 (list):
  list sub-command REMOVE_ITEM requires list to be present.
Call Stack (most recent call first):
  src/widgets/CMakeLists.txt:88 (tqt_automoc)


CMake Error at TQtMacros.cmake:228 (list):
  list sub-command REMOVE_ITEM requires list to be present.
Call Stack (most recent call first):
  src/widgets/CMakeLists.txt:88 (tqt_automoc)


CMake Error at TQtMacros.cmake:228 (list):
  list sub-command REMOVE_ITEM requires list to be present.
Call Stack (most recent call first):
  src/widgets/CMakeLists.txt:88 (tqt_automoc)


CMake Error at TQtMacros.cmake:228 (list):
  list sub-command REMOVE_ITEM requires list to be present.
Call Stack (most recent call first):
  src/widgets/CMakeLists.txt:88 (tqt_automoc)


CMake Error at TQtMacros.cmake:228 (list):
  list sub-command REMOVE_ITEM requires list to be present.
Call Stack (most recent call first):
  src/widgets/CMakeLists.txt:88 (tqt_automoc)


CMake Error at TQtMacros.cmake:228 (list):
  list sub-command REMOVE_ITEM requires list to be present.
Call Stack (most recent call first):
  src/workspace/CMakeLists.txt:27 (tqt_automoc)


-- Configuring incomplete, errors occurred!

I get this error today (didn't have any yesterday):

CMake Error at TQtMacros.cmake:228 (list):
  list sub-command REMOVE_ITEM requires list to be present.
Call Stack (most recent call first):
  src/table/CMakeLists.txt:27 (tqt_automoc)

.
.
.

-- Configuring incomplete, errors occurred!

This should be fixed by the previous commit.

@SlavekB can you give It a building test "as-is"?

I expect many things to be fixed but "as-is" the core tqt3 with default options should build.

I made the test "as-is" and it was successful. As expected, the resulting library cannot work because it does not provide anything.

I added two minor commits:

Current DEB packages are built with UnixODBC, so I added detection and use UnixODBC next to libiodbc.
Although OpenGL detection has been successfully performed, in ntqmodules.h has not been defined TQT_MODULE_OPENGL. In any case, it will probably need some more work due to QT_DLOPEN_OPENGL. I didn't deal with it now.

Of course, both deserve a squash to the main CMake conversion commit.

To clarify the previous comment: Because the purpose of the library is to provide all exported functions, there is a need instead of linking to connect modules to the final library to use EMBED. Indeed, exactly for this purpose there is a defined variable qtlib_embed to which the modules are added. I tried instead of LINK to use EMBED ${qtlib_embed}, but this caused problems that we need to explore and solve.

Solving problems for changing from linking to embedding has shown to be easier than I expected. So I added the third commit that made a mentioned change for embedding modules to the target library. Now the library has increased its size significantly and should provide expected functions.

I expect many things to be fixed but "as-is" the core tqt3 with default options should build.

Great work Greg, really looking forward for when this is ready :-)

I have removed explicite linking with the threading library from the kernel-static lib otherwise It ends up in FTBFS on my system, none of the tutorials passes.

Please check on your platform.
On my system when I build with CMAKE_VERBOSE_MAKEFILE=ON I see that the static libs that needs threading get both the TQT_THREAD_SUPPORT definition and the -lpthread library, as a result the tutorials pass.

I just did a test building the current state and fixed FTBFS.
No more research I did in this moment.

I have made many changes, many things are still unfinished, many things still require remodeling. It is great that there is more interest in working with this task. There are a number of things that will have to be discussed before it gets the final state. Many of these things are already mentioned in #117.