WIP:Conversion to the cmake building system: second attempt #117

I'm willing to continue to work upon tqt conversion to cmake. I've already made some changes to the branch left behind by Gregory.

The reset of the post is summary of the current status of the project, which hopefully will be updated .

Any suggestions and comments are welcome.

Map of ./configure options to cmake

Here are some maps from old ./configure's options to the cmake's one.

Configuration options

Some notations:

[ ] - untested option
[@] - option doesn't causes build failure (at list in conjunction with some other options)
[V] - it is tested that option actually does what it advertises
??? - option is absent and it is up to discussion if we should add it
!!! - option is currently missing
--- - option is dropped or unsupported

TQt Modules selection

./configure	cmake	ON	OFF
`-enable-tools`	`BUILD_MODULE_TOOLS`	`[V]`	`---`
`-enable-kernel`	`BUILD_MODULE_KERNEL`	`[V]`	`---`
`-enable-widgets`	`BUILD_MODULE_WIDGETS`	`[V]`	`---`
`-enable-dialogs`	`BUILD_MODULE_DIALOGS`	`[V]`	`---`
`-enable-workspace`	`BUILD_MODULE_WORKSPACE`	`[V]`	`[V]`
`-enable-inputmethod`	`BUILD_MODULE_INPUTMETHOD`	`[V]`	`[V]`
`-enable-network`	`BUILD_MODULE_NETWORK`	`[V]`	`[V]`
`-enable-canvas`	`BUILD_MODULE_CANVAS`	`[V]`	`[V]`
`-enable-table`	`BUILD_MODULE_TABLE`	`[V]`	`[V]`
`-enable-xml`	`BUILD_MODULE_XML`	`[V]`	`[V]`
`-enable-opengl`	`BUILD_MODULE_OPENGL`	`[V]`	`[V]`
`-enable-styles`	`BUILD_MODULE_STYLES`	`[V]`	`[V]`
`-enable-sql`	`BUILD_MODULE_SQL`	`[V]`	`[V]`

General options

./configure	cmake	ON	OFF
`-thread`	`!!!`
`-nis`	`!!!`
`-cups`	`WITH_CUPS`	`[@]`	`[@]`
`-ipv6`	`WITH_IPV6`	`[@]`	`[@]`
`-platform=<mkspec>`	* `-WITH_PLATFORM=<mkspec>`	`[V]`	`[@]`

Unlike ./configure the option doesn't set CFLAGS, also if omitted it won't autoselect a qplatformdefs.h from the set of provided one, but rather it will generate a new one from scratch.

Code generation options

./configure	cmake	ON	OFF
`-stl`	`WITH_STL`	`[@]`	`[@]`
`-pch`	`???`
`-exceptions`	`???`
-static	`???`
-version-script	`???`

Poorly documented, but useful options

./configure	cmake	ON	OFF
-accessibility	`BUILD_ACCESSIBILITY`	`[ ]`	`[ ]`
-largefile	`???`
-glibmainloop	`WITH_GLIBMAINLOOP`	`[@]`	`[@]`

Poorly documented and probably unneeded options

-big-codecs
-endian
-freetype
-incremental
-tqvfb

X11 options

./configure	cmake	ON	OFF
`-system-nas-sound`	`WITH_SOUND`	`[@]`	`[@]`
`-sm`	`WITH_SM`	`[@]`	`[@]`
`-xshape`	`WITH_XSHAPE`	`[@]`	`[@]`
`-xinerama`	`WITH_XINERAMA`	`[@]`	`[@]`
`-xcursor`	`WITH_XCURSOR`	`[@]`	`[@]`
`-xrandr`	`WITH_XRANDR`	`[@]`	`[@]`
`-xrender`	`WITH_XRENDER`	`[@]`	`[@]`
`-xft`	`WITH_XFT`	`[@]`	`[@]`
`-tablet`	`WITH_TABLET`	`[@]`	`[@]`
`-xkb`	`WITH_XKB`	`[@]`	`[@]`
`-inputmethod`	* `---`	`---`	`---`
`-inputmethod-ext`	`WITH_IMMODULE_EXTENSIONS`	`[@]`	`[@]`
`???`	`WITH_XSYNC`	`[@]`	`[@]`
`-dlopen-opengl`	`???`

-inputmethod is broken and doesn't do or can do anything beyond what -disable-inputmethod does

SQL drivers

./configure	cmake	ON	OFF
`-qt-sql-ibase`	`WITH_SQL_DRIVER_PSQL`	`[V]`	`[V]`
`-qt-sql-mysql`	`WITH_SQL_DRIVER_MYSQL`	`[V]`	`[V]`
`-qt-sql-odbc`	`WITH_SQL_DRIVER_ODBC`	`[V]`	`[V]`
`-qt-sql-psql`	`WITH_SQL_DRIVER_IBASE`	`[V]`	`[V]`
`-qt-sql-sqlite`	`???`
`-qt-sql-sqlite3`	`WITH_SQL_DRIVER_SQL3`	`[V]`	`[V]`
-------------------------	-------------------------------	-----	------
`-plugin-sql-ibase`	`BUILD_SQL_PLUGIN_PSQL`	`[V]`	`[V]`
`-plugin-sql-mysql`	`BUILD_SQL_PLUGIN_MYSQL`	`[V]`	`[V]`
`-plugin-sql-odbc`	`BUILD_SQL_PLUGIN_ODBC`	`[V]`	`[V]`
`-plugin-sql-psql`	`BUILD_SQL_PLUGIN_IBASE`	`[V]`	`[V]`
`-plugin-sql-sqlite`	`???`
`-plugin-sql-sqlite3`	`BUILD_SQL_PLUGIN_SQL3`	`[V]`	`[V]`

Styles

./configure	cmake	ON	OFF
`-qt-style-motif`	`WITH_STYLE_MOTIF`	`[V]`	`[V]`
`-qt-style-windows`	`WITH_STYLE_WINDOWS`	`[V]`	`[V]`
`-qt-style-cde`	`WITH_STYLE_CDE`	`[V]`	`[V]`
`-qt-style-motifplus`	`WITH_STYLE_MOTIFPLUS`	`[V]`	`[V]`
`-qt-style-sgi`	`WITH_STYLE_SGI`	`[V]`	`[V]`
`-qt-style-compact`	`WITH_STYLE_COMPACT`	`[V]`	`[V]`
`-qt-style-platinum`	`WITH_STYLE_PLATINUM`	`[V]`	`[V]`
???	`WITH_STYLE_INTERLACE`	`[V]`	`[V]`
-------------------------	-------------------------------	-----	------
`-plugin-style-motif`	`BUILD_STYLE_PLUGIN_MOTIF`	`[V]`	`[V]`
`-plugin-style-windows`	`BUILD_STYLE_PLUGIN_WINDOWS`	`[V]`	`[V]`
`-plugin-style-cde`	`BUILD_STYLE_PLUGIN_CDE`	`[V]`	`[V]`
`-plugin-style-motifplus`	`BUILD_STYLE_PLUGIN_MOTIFPLUS`	`[V]`	`[V]`
`-plugin-style-sgi`	`BUILD_STYLE_PLUGIN_SGI`	`[V]`	`[V]`
`-plugin-style-compact`	`BUILD_STYLE_PLUGIN_COMPACT`	`[V]`	`[V]`
`-plugin-style-platinum`	`BUILD_STYLE_PLUGIN_PLATINUM`	`[V]`	`[V]`
???	`BUILD_STYLE_PLUGIN_INTERLACE`	`[V]`	`[V]`

Image formats

./configure	cmake	ON	OFF
`-qt-imgfmt-png`	`WITH_IMGFMT_PNG`	`[V]`	`[V]`
`-qt-imgfmt-jpeg`	`WITH_IMGFMT_JPEG`	`[V]`	`[V]`
`-qt-imgfmt-mng`	`WITH_IMGFMT_MNG`	`[V]`	`[V]`
`-gif`	`WITH_IMGFMT_GIF`	`[V]`	`[V]`
-------------------------	-------------------------------	-----	------
`-plugin-imgfmt-png`	`BUILD_IMGFMT_PLUGIN_PNG`	`[V]`	`[V]`
`-plugin-imgfmt-jpeg`	`BUILD_IMGFMT_PLUGIN_JPEG`	`[V]`	`[V]`
`-plugin-imgfmt-mng`	`BUILD_IMGFMT_PLUGIN_MNG`	`[V]`	`[V]`

Inputmethod plugins

./configure	cmake	ON	OFF
* `imsw-multi`	`BUILD_IM_PLUGIN_IMSW_MULTI`	`!!!`	`!!!`
* `imsw-none`	`BUILD_IM_PLUGIN_IMSW_NONE`	`!!!`	`!!!`
* `simple`	`BUILD_IM_PLUGIN_SIMPLE`	`!!!`	`!!!`
* `xim`	`BUILD_IM_PLUGIN_XIM`	`!!!`	`!!!`

Input method plugins don't have corresponding options in ./configure

Remaining tasks:

Had to be done

QT_INSTALL_* paths and *_INSTALL_DIR from TDESetupPaths may be different: either synchronize them or get rid of one
Check if any options we are dropping are useful in any way (see ./configure to cmake option's map tables above)
Check changes in Q*->TQ* macros renames
Build inputmethods plugins
tqt-mt.pc:
- Export qt_config
- Save Cflags
Use flex and yacc to generate moc's code
Provide some sane qmake.conf configuration for local (generated) mkspecs
Add optional support for -thread and -nis.
Check if any tools depend upon a module

Probably should be done

Install docs
Install examples and tutorials
Update translations
Some more pronounce tests for platforms
Some default CFLAGS/CXXFLAGS for specific platforms
Move libfbclient (for sql-ibase) detection into a dedicated cmake Find-module
Self-contained build for examples/tutorials i.e. you should be to cp examples/aclock /tmp && cd /tmp/aclock && cmake . && make
Fix compilation of all examples/tutorials
Build uic separately from the designer
Rename BUILD_ACCESSIBILITY -> WITH_ACCESSIBILITY
Creating symlinks to headers in ${CMAKE_BUILD_DIR}/include takes surprisingly a lot of time. We probably should get rid of that.
Support for independent build of plugins (sql drivers, styles and image formats) against already installed qt
Separate build of tools
tqt-mt.pc:
- Save translationsdir
- Save all the Libs

Current problems

When built with -DBUILD_IMGFMT_PLUGIN_PNG=ON, designer FTBFS
mng support was switched to be detected by pkg_config. Some distros don't provide it, so switch back to old-school detection.

Finished tasks

Build tools:
- assistant
- designer (and uic particularly)
- linguist
- other: maketqpf, msg2tqm, qembed, qtconfig, tqtmergetr, tqvfb
Install translations
There is config.h added by Gregory, which is not really needed. We probably should remove it.
Support building sql drivers, styles and image formats as plugins
Check modules dependencies on each other during configuration.
Use a (probably generate) actual qplatformdefs.h instead of nailing it to mkspecs/linux-g++-64
Install mkspecs

Questions to discuss

Do we need support for bundled libraries?
- Those that could be easily replaced (libpng, libjpeg, libmng, zlib)?
- The obsolete one (sqlite)?
- What about opentype? I'm not yet sure is it possible to easily replace it...
Do we need support build of static libraries?
Do we need precompiled headers support?
Should the moc be called tqmoc or tmoc? The same thing for uic.
QT_INSTALL_* paths and *_INSTALL_DIR from TDESetupPaths may conflict with each other. How should we resolve this?
Should we provide analogues for -exception/-no-exception?
We don't need to build qconfig, right?
What should we do about the library's name? lintqt - libtqt-mt?

Resolved questions

Currently options for selecting TQt's modules look IMHO too similar to those which select what utilities to build (BUILD_TQMAKE vs BUILD_DIALOGS). I suggest to rename those to something like WITH_MODULE_*, WITH_MOD_* or WITH_TQTMOD_*. Your thoughts? Any ideas for better naming?

Already done by Slavek
How do we want to control if a plugin is built as a plugin or built directly into tqt-mt.so (i.e. -qt-sql-sqlite3 vs -plugin-sql-sqlite3 vs -no-sql-sqlite3)? I'd suggest tri-state cmake options with values ON/OFF/PLUGIN. Would it be ok for everybody?

No, use WITH_*_… option for building the plugin into the lib and BUILD_*_PLUGIN_… for building it as a shared library. WITH_*_…=ON && BUILD_*_PLUGIN_…=ON and WITH_*_…=OFF && BUILD_*_PLUGIN_…=ON will both result in plugin being built as a shared library. 1 2 3
I was thinking on renaming WITH_LIBMNG -> WITH_MNG.Any thoughts?

Was asked, it seems there were no objections.
Which platforms/architectures do we wish to support? Can we don't provide explicit support for platforms that are on a more weird side like e.g. hpux-acc? Do we want to provide any support for platforms like win32 or mac?

We will provide an option to use old qplatformdefs.h definitions as-is. For the generated one we will start with modern-enough Linux and FreeBSD and provide support to other platforms on an on-demand basis. 1 2 3
Do we really need per-tutorial and per-example build flags (BUILD_T* and BUILD_ACLOCK..BUILD_DEMO)?

No, We don't. 1
What to do with -inputmethod / -enable-inputmethod?

Keep -enable-inputmethod, ditch -inputmethod, due to they being essentially the same option. See rational in description of fad4acbe

For anyone who was brave enough to scroll till the end, first of all, thanks for that and, secondly and once again, any suggestions and comments are welcome.

I'm willing to continue to work upon tqt conversion to cmake. I've already made some changes to the [branch](https://mirror.git.trinitydesktop.org/gitea/TDE/tqt3/pulls/46) left behind by Gregory. The reset of the post is summary of the current status of the project, which hopefully will be updated . Any suggestions and comments are welcome. ## Map of ./configure options to cmake Here are some maps from old `./configure`'s options to the cmake's one. <details> <summary> Configuration options </summary> ### Some notations: - `[ ]` - untested option - `[@]` - option doesn't causes build failure (at list in conjunction with some other options) - `[V]` - it is tested that option actually does what it advertises - `???` - option is absent and it is up to discussion if we should add it - `!!!` - option is currently missing - `---` - option is dropped or unsupported ### TQt Modules selection | ./configure | cmake | ON | OFF | | --------------------- | -------------------------- | ----- | ----- | | `-enable-tools` | `BUILD_MODULE_TOOLS` | `[V]` | `---` | | `-enable-kernel` | `BUILD_MODULE_KERNEL` | `[V]` | `---` | | `-enable-widgets` | `BUILD_MODULE_WIDGETS` | `[V]` | `---` | | `-enable-dialogs` | `BUILD_MODULE_DIALOGS` | `[V]` | `---` | | `-enable-workspace` | `BUILD_MODULE_WORKSPACE` | `[V]` | `[V]` | | `-enable-inputmethod` | `BUILD_MODULE_INPUTMETHOD` | `[V]` | `[V]` | | `-enable-network` | `BUILD_MODULE_NETWORK` | `[V]` | `[V]` | | `-enable-canvas` | `BUILD_MODULE_CANVAS` | `[V]` | `[V]` | | `-enable-table` | `BUILD_MODULE_TABLE` | `[V]` | `[V]` | | `-enable-xml` | `BUILD_MODULE_XML` | `[V]` | `[V]` | | `-enable-opengl` | `BUILD_MODULE_OPENGL` | `[V]` | `[V]` | | `-enable-styles` | `BUILD_MODULE_STYLES` | `[V]` | `[V]` | | `-enable-sql` | `BUILD_MODULE_SQL` | `[V]` | `[V]` | ### General options | ./configure | cmake | ON | OFF | | -------------------- | --------------------------- | ----- | ----- | | `-thread` | `!!!` | ` ` | ` ` | | `-nis` | `!!!` | ` ` | ` ` | | `-cups` | `WITH_CUPS` | `[@]` | `[@]` | | `-ipv6` | `WITH_IPV6` | `[@]` | `[@]` | | `-platform=<mkspec>` | * `-WITH_PLATFORM=<mkspec>` | `[V]` | `[@]` | * Unlike ./configure the option doesn't set CFLAGS, also if omitted it won't autoselect a `qplatformdefs.h` from the set of provided one, but rather it will generate a new one from scratch. ### Code generation options | ./configure | cmake | ON | OFF | | ------------------ | -------------------------- | ----- | ----- | | `-stl` | `WITH_STL` | `[@]` | `[@]` | | `-pch` | `???` | ` ` | ` ` | | `-exceptions` | `???` | ` ` | ` ` | | -static | `???` | ` ` | ` ` | | -version-script | `???` | ` ` | ` ` | ### Poorly documented, but useful options | ./configure | cmake | ON | OFF | | ------------------ | -------------------------- | ----- | ----- | | -accessibility | `BUILD_ACCESSIBILITY` | `[ ]` | `[ ]` | | -largefile | `???` | ` ` | ` ` | | -glibmainloop | `WITH_GLIBMAINLOOP` | `[@]` | `[@]` | ### Poorly documented and probably unneeded options - `-big-codecs` - `-endian` - `-freetype` - `-incremental` - `-tqvfb` ### X11 options | ./configure | cmake | ON | OFF | | ------------------ | -------------------------- | ----- | ----- | | `-system-nas-sound`| `WITH_SOUND` | `[@]` | `[@]` | | `-sm` | `WITH_SM` | `[@]` | `[@]` | | `-xshape` | `WITH_XSHAPE` | `[@]` | `[@]` | | `-xinerama` | `WITH_XINERAMA` | `[@]` | `[@]` | | `-xcursor` | `WITH_XCURSOR` | `[@]` | `[@]` | | `-xrandr` | `WITH_XRANDR` | `[@]` | `[@]` | | `-xrender` | `WITH_XRENDER` | `[@]` | `[@]` | | `-xft` | `WITH_XFT` | `[@]` | `[@]` | | `-tablet` | `WITH_TABLET` | `[@]` | `[@]` | | `-xkb` | `WITH_XKB` | `[@]` | `[@]` | | `-inputmethod` | * `---` | `---` | `---` | | `-inputmethod-ext` | `WITH_IMMODULE_EXTENSIONS` | `[@]` | `[@]` | | `???` | `WITH_XSYNC` | `[@]` | `[@]` | | `-dlopen-opengl` | `???` | ` ` | ` ` | * `-inputmethod` is broken and doesn't do or can do anything beyond what `-disable-inputmethod` does ### SQL drivers | ./configure | cmake | ON | OFF | | ------------------------- | ------------------------------ | ----- |------ | | `-qt-sql-ibase` | `WITH_SQL_DRIVER_PSQL` | `[V]` | `[V]` | | `-qt-sql-mysql` | `WITH_SQL_DRIVER_MYSQL` | `[V]` | `[V]` | | `-qt-sql-odbc` | `WITH_SQL_DRIVER_ODBC` | `[V]` | `[V]` | | `-qt-sql-psql` | `WITH_SQL_DRIVER_IBASE` | `[V]` | `[V]` | | `-qt-sql-sqlite` | `???` | | ` ` | | `-qt-sql-sqlite3` | `WITH_SQL_DRIVER_SQL3` | `[V]` | `[V]` | | ------------------------- | -------------------------------| ----- |------ | | `-plugin-sql-ibase` | `BUILD_SQL_PLUGIN_PSQL` | `[V]` | `[V]` | | `-plugin-sql-mysql` | `BUILD_SQL_PLUGIN_MYSQL` | `[V]` | `[V]` | | `-plugin-sql-odbc` | `BUILD_SQL_PLUGIN_ODBC` | `[V]` | `[V]` | | `-plugin-sql-psql` | `BUILD_SQL_PLUGIN_IBASE` | `[V]` | `[V]` | | `-plugin-sql-sqlite` | `???` | | ` ` | | `-plugin-sql-sqlite3` | `BUILD_SQL_PLUGIN_SQL3` | `[V]` | `[V]` | ### Styles | ./configure | cmake | ON | OFF | | ------------------------- | -------------------------------| ----- |------ | | `-qt-style-motif` | `WITH_STYLE_MOTIF` | `[V]` | `[V]` | | `-qt-style-windows` | `WITH_STYLE_WINDOWS` | `[V]` | `[V]` | | `-qt-style-cde` | `WITH_STYLE_CDE` | `[V]` | `[V]` | | `-qt-style-motifplus` | `WITH_STYLE_MOTIFPLUS` | `[V]` | `[V]` | | `-qt-style-sgi` | `WITH_STYLE_SGI` | `[V]` | `[V]` | | `-qt-style-compact` | `WITH_STYLE_COMPACT` | `[V]` | `[V]` | | `-qt-style-platinum` | `WITH_STYLE_PLATINUM` | `[V]` | `[V]` | | ??? | `WITH_STYLE_INTERLACE` | `[V]` | `[V]` | | ------------------------- | -------------------------------| ----- |------ | | `-plugin-style-motif` | `BUILD_STYLE_PLUGIN_MOTIF` | `[V]` | `[V]` | | `-plugin-style-windows` | `BUILD_STYLE_PLUGIN_WINDOWS` | `[V]` | `[V]` | | `-plugin-style-cde` | `BUILD_STYLE_PLUGIN_CDE` | `[V]` | `[V]` | | `-plugin-style-motifplus` | `BUILD_STYLE_PLUGIN_MOTIFPLUS` | `[V]` | `[V]` | | `-plugin-style-sgi` | `BUILD_STYLE_PLUGIN_SGI` | `[V]` | `[V]` | | `-plugin-style-compact` | `BUILD_STYLE_PLUGIN_COMPACT` | `[V]` | `[V]` | | `-plugin-style-platinum` | `BUILD_STYLE_PLUGIN_PLATINUM` | `[V]` | `[V]` | | ??? | `BUILD_STYLE_PLUGIN_INTERLACE` | `[V]` | `[V]` | ### Image formats | ./configure | cmake | ON | OFF | | ------------------------- | ------------------------------ | ----- |------ | | `-qt-imgfmt-png` | `WITH_IMGFMT_PNG` | `[V]` | `[V]` | | `-qt-imgfmt-jpeg` | `WITH_IMGFMT_JPEG` | `[V]` | `[V]` | | `-qt-imgfmt-mng` | `WITH_IMGFMT_MNG` | `[V]` | `[V]` | | `-gif` | `WITH_IMGFMT_GIF` | `[V]` | `[V]` | | ------------------------- | -------------------------------| ----- |------ | | `-plugin-imgfmt-png` | `BUILD_IMGFMT_PLUGIN_PNG` | `[V]` | `[V]` | | `-plugin-imgfmt-jpeg` | `BUILD_IMGFMT_PLUGIN_JPEG` | `[V]` | `[V]` | | `-plugin-imgfmt-mng` | `BUILD_IMGFMT_PLUGIN_MNG` | `[V]` | `[V]` | ### Inputmethod plugins | ./configure | cmake | ON | OFF | | ------------------------- | -------------------------------| ----- |------ | | * `imsw-multi` | `BUILD_IM_PLUGIN_IMSW_MULTI` | `!!!` | `!!!` | | * `imsw-none` | `BUILD_IM_PLUGIN_IMSW_NONE` | `!!!` | `!!!` | | * `simple` | `BUILD_IM_PLUGIN_SIMPLE` | `!!!` | `!!!` | | * `xim` | `BUILD_IM_PLUGIN_XIM` | `!!!` | `!!!` | * Input method plugins don't have corresponding options in `./configure` </details> ----- ## Remaining tasks: ### Had to be done - `QT_INSTALL_*` paths and `*_INSTALL_DIR` from `TDESetupPaths` may be different: either synchronize them or get rid of one - Check if any options we are dropping are useful in any way (see `./configure` to `cmake` option's map tables above) - Check changes in `Q*`->`TQ*` macros renames - Build inputmethods plugins - `tqt-mt.pc`: - Export `qt_config` - Save `Cflags` - Use flex and yacc to generate moc's code - Provide some sane qmake.conf configuration for local (generated) mkspecs - Add optional support for `-thread` and `-nis`. - Check if any tools depend upon a module ### Probably should be done - Install docs - Install examples and tutorials - Update translations - Some more pronounce tests for platforms - Some default CFLAGS/CXXFLAGS for specific platforms - Move `libfbclient` (for sql-ibase) detection into a dedicated cmake Find-module - Self-contained build for examples/tutorials i.e. you should be to `cp examples/aclock /tmp && cd /tmp/aclock && cmake . && make` - Fix compilation of all examples/tutorials - Build `uic` separately from the `designer` - Rename `BUILD_ACCESSIBILITY` -> `WITH_ACCESSIBILITY` - Creating symlinks to headers in `${CMAKE_BUILD_DIR}/include` takes surprisingly a lot of time. We probably should get rid of that. - Support for independent build of plugins (sql drivers, styles and image formats) against already installed qt - Separate build of tools - `tqt-mt.pc`: - Save `translationsdir` - Save all the `Libs` ### Current problems - When built with `-DBUILD_IMGFMT_PLUGIN_PNG=ON`, `designer` FTBFS - `mng` support was switched to be detected by `pkg_config`. Some distros don't provide it, so switch back to old-school detection. <details> <summary> Finished tasks </summary> - Build tools: - assistant - designer (and uic particularly) - linguist - other: maketqpf, msg2tqm, qembed, qtconfig, tqtmergetr, tqvfb - Install translations - There is `config.h` added by Gregory, which is not really needed. We probably should remove it. - Support building sql drivers, styles and image formats as plugins - Check modules dependencies on each other during configuration. - Use a (probably generate) actual `qplatformdefs.h` instead of nailing it to `mkspecs/linux-g++-64` - Install mkspecs </details> ----- ## Questions to discuss - Do we need support for bundled libraries? - Those that could be easily replaced (libpng, libjpeg, libmng, zlib)? - The obsolete one (sqlite)? - What about `opentype`? I'm not yet sure is it possible to easily replace it... - Do we need support build of static libraries? - Do we need precompiled headers support? - Should the `moc` be called `tqmoc` or `tmoc`? The same thing for `uic`. - `QT_INSTALL_*` paths and `*_INSTALL_DIR` from `TDESetupPaths` may conflict with each other. How should we resolve this? - Should we provide analogues for `-exception`/`-no-exception`? - We don't need to build `qconfig`, right? - What should we do about the library's name? lintqt - libtqt-mt? <details> <summary> Resolved questions </summary> - Currently options for selecting TQt's modules look IMHO too similar to those which select what utilities to build (`BUILD_TQMAKE` vs `BUILD_DIALOGS`). I suggest to rename those to something like `WITH_MODULE_*`, `WITH_MOD_*` or `WITH_TQTMOD_*`. Your thoughts? Any ideas for better naming? : <br>Already done by Slavek - How do we want to control if a plugin is built as a plugin or built directly into `tqt-mt.so` (i.e. `-qt-sql-sqlite3` vs `-plugin-sql-sqlite3` vs `-no-sql-sqlite3`)? I'd suggest tri-state cmake options with values `ON`/`OFF`/`PLUGIN`. Would it be ok for everybody? : <br>No, use `WITH_*_…` option for building the plugin into the lib and `BUILD_*_PLUGIN_…` for building it as a shared library. `WITH_*_…=ON && BUILD_*_PLUGIN_…=ON` and `WITH_*_…=OFF && BUILD_*_PLUGIN_…=ON` will both result in plugin being built as a shared library. [1](https://mirror.git.trinitydesktop.org/gitea/TDE/tqt3/pulls/117#issuecomment-45060) [2](https://mirror.git.trinitydesktop.org/gitea/TDE/tqt3/pulls/117#issuecomment-45084) [3](https://mirror.git.trinitydesktop.org/gitea/TDE/tqt3/pulls/117#issuecomment-45097) - I was thinking on renaming `WITH_LIBMNG` -> `WITH_MNG`.Any thoughts? : <br>Was [asked](https://mirror.git.trinitydesktop.org/gitea/TDE/tqt3/pulls/117#issuecomment-45100), it seems there were no objections. - Which platforms/architectures do we wish to support? Can we don't provide explicit support for platforms that are on a more weird side like e.g. `hpux-acc`? Do we want to provide any support for platforms like win32 or mac? : We will provide an option to use old `qplatformdefs.h` definitions as-is. For the generated one we will start with modern-enough Linux and FreeBSD and provide support to other platforms on an on-demand basis. [1](https://mirror.git.trinitydesktop.org/gitea/TDE/tqt3/pulls/117#issuecomment-45272) [2](https://mirror.git.trinitydesktop.org/gitea/TDE/tqt3/pulls/117#issuecomment-45606) [3](https://mirror.git.trinitydesktop.org/gitea/TDE/tqt3/pulls/117#issuecomment-45628) - Do we really need per-tutorial and per-example build flags (`BUILD_T*` and `BUILD_ACLOCK`..`BUILD_DEMO`)? : No, We don't. [1](https://mirror.git.trinitydesktop.org/gitea/TDE/tqt3/pulls/117#issuecomment-45575) - What to do with -inputmethod / -enable-inputmethod? : Keep `-enable-inputmethod`, ditch `-inputmethod`, due to they being essentially the same option. See rational in description of fad4acbe </details> ----- For anyone who was brave enough to scroll till the end, first of all, thanks for that and, secondly and once again, any suggestions and comments are welcome.

Oh, oh, I also made many other adjustments and move forward with CMake conversion. Only I haven't pushed it yet, because I have a few more things I wanted to finish before pushing it. I will push my adjustments to the original PR as soon as possible and then we should synchronize to merge our changes and move forward together.

@SlavekB, ok, I'm looking forward towards it, though I didn't made a lot yet. Frankly speaking everything but rewriting of the tqt_automoc() to be more precise about which headers we moc is quite minor and mostly cosmetic changes...

I pushed my changes. As you can see, I am currently working on CMake conversion for tools – I wanted to finish it first, but it does not matter, better to share the code earlier when there are more who wants to work on it. I assume that it will currently be quite viable to merge our changes.

You can see that I have already added new options for building SQL as build-in modules × plugins. Options WITH_MODULE_... are added as you intended. Changing options for styles is very similar to the one that you did. In addition, there is also the option of BUILD_LIB. For example, on BSD systems, tqmake is built separately, without a library as such. That is why I wanted the building the library as such to be optional.

I pushed my changes.

It seems you squashed everything, didn't you? Was it by accident?
It'd be not that easy to cherry-pick from that not to mention that authorship information will be lost...

Yes I did squash. Indeed, squash has been made several times earlier, because there was a cooperation between me and Greg. There it seems unnecessary in the finals to leave the individual partial commits, which during the stage of development in the branch changes each other when it has not yet merged. As you can see, there are all authors listed in Signed-off-by.

Some more notes:

I have made squash long time ago, because I assumed that further work would be my task. Therefore, other gradual changes I incorporated into the previously made squash.
We can use the original branch to make the cherry-pick of your commit to this original branch. Because we use a model with shared branches, it is possible for more authors to cooperate smoothly within one branch.
For the future squash, we can give in detail the individual merit of authorship divided according to the authors in the git log.

Nice, so are we going to continue the conversion on the original PR #46 or here?

@SlavekB, yep... I'll probably cherry pick from my branch upon your commit... though it would be easier if it were possible to reorder some commits with your changes...

Nice, so are we going to continue the conversion on the original PR #46 or here?

Probably here... I'd like to keep the current status updated in the header message...

I'd like to discuss a more specific question, sooner:

How do we want to control if a plugin is built as a plugin or built directly into tqt-mt.so (i.e. -qt-sql-sqlite3 vs -plugin-sql-sqlite3 vs -no-sql-sqlite3)? I'd suggest tri-state cmake options with values ON/OFF/PLUGIN. Would it be ok for everybody?

As for now @SlavekB prepared the two sets of variables: WITH_SQL_DRIVER_* and WITH_SQL_PLUGINS_* for that, but I feel it'd get a bit cumbersome, because the same thing would have to be done for image formats and styles...

How do you feel about tri-state options variant?

Here is definitely a better description of the state, migration of choises and questions that will need to be discussed. On the other hand, in the original PR is done more work.

I assume that it will be more feasible to reorder commits and move your commits above the updated state of the original PR or make the cherry-pick of your commits above the updated state of the original PR. Which of us will do that?

For SQL plugins there is a clear opinion:

WITH_... are choises that affect build-in library posibilities.

BUILD_... are choices that affect things that are separate – independent binaries, independend libraries – ie plugins. So here it is unambiguous that for the plugins should be used BUILD_... => plugins can be build even separately with BUILD_LIB=OFF.

Therefore, in my updated state, there are clearly distinguished options WITH_SQL_MODULE_... × BUILD_SQL_PLUGIN_....

Therefore, in my updated state, there are clearly distinguished options WITH_SQL_MODULE_... × BUILD_SQL_PLUGIN_....

The problem with that is it's essentially the same code that can be either built as a plugin or built into the library, there is little sense in doing both i.e. WITH_SQL_MODULE_…=ON BUILD_SQL_PLUGIN_…=ON, so we would probably have to ban that configuration.

Therefore, in my updated state, there are clearly distinguished options WITH_SQL_MODULE_... × BUILD_SQL_PLUGIN_....

The problem with that is it's essentially the same code that can be either built as a plugin or built into the library, there is little sense in doing both i.e. WITH_SQL_MODULE_…=ON BUILD_SQL_PLUGIN_…=ON, so we would probably have to ban that configuration.

Yes, there makes no sense to use both options at the same time. But both options have their clear behavior. It would be very confusing when to build only plugin (without a library) the option would be WITH_SQL_... Therefore, there is a clear difference for the use of BUILD_... × WITH_....

The question is whether it is necessary to deal with ban for current turn on of both options. Although it makes no sense to turn on both options, it will not cause any problem. On the other hand, yes, it would be better to point out the user that selected options make no sense.

You may notice that on FreeBSD are as a separate ports tqmake, library as such and individual SQL plugins.

ok... I'm not actually very opposed to the idea of two variables... just wanted to make all the implications clear.

Let's talk semantics... I see next variants:

WITH_SQL_DRIVER_…=ON × BUILD_SQL_PLUGIN_…=ON -> build both
WITH_SQL_DRIVER_…=OFF× BUILD_SQL_PLUGIN_…=ON -> build as plugin
WITH_SQL_DRIVER_…=ON × BUILD_SQL_PLUGIN_…=OFF-> build-into lib
WITH_SQL_DRIVER_…=ON × BUILD_SQL_PLUGIN_…=ON -> error
WITH_SQL_DRIVER_…=OFF× BUILD_SQL_PLUGIN_…=ON -> build as plugin
WITH_SQL_DRIVER_…=ON × BUILD_SQL_PLUGIN_…=OFF-> build-into lib
WITH_SQL_DRIVER_…=ON × BUILD_SQL_PLUGIN_…=ON -> build as plugin
WITH_SQL_DRIVER_…=OFF× BUILD_SQL_PLUGIN_…=ON -> error
WITH_SQL_DRIVER_…=ON × BUILD_SQL_PLUGIN_…=OFF-> build-into lib
WITH_SQL_DRIVER_…=ON × BUILD_SQL_PLUGIN_…=ON -> build as plugin
WITH_SQL_DRIVER_…=OFF× BUILD_SQL_PLUGIN_…=ON -> build as plugin
WITH_SQL_DRIVER_…=ON × BUILD_SQL_PLUGIN_…=OFF-> build-into lib

I really dislike the first one, and more inclined towards the last one. Your thoughts?

I tried to do test with the original QMake and it seems that it is possible to turn on the parallel build of driver and plugin and it does not alert that such a configuration lacks meaning => it is like variant 1.

Variant 2 makes sense if we want the user to know that its configuration does not make sense. This is most different from the current state with QMake.

Variant 3 lacks sense. The option BUILD_SQL_PLUGIN_... has a meaning regardless of whether the library as such is built => BUILD_LIB can be OFF so WITH_SQL_DRIVER_... are not applied. Therefore, it makes no sense to affect the BUILD_SQL_PLUGIN_.... We can reject it immediately.

Variant 4 I like. This will not cause crash, as variant 2, and makes a solution that makes the best sense. I propose to go on the way of variant 4 and if @MicheleC has a different opinion, we can adjust it later.

I also prefer option 4. Basically it is like BUILD_SQL_PLUGIN_… has higher priority than WITH_SQL_DRIVER_…, which somehow (for no reason) seems more logical :-)
Probably good to add a comment in the cmake files explaining that those BUILD options have priority over the corresponding WITH options.

ok... this one settled... I've rebased the branch upon the @SlavekB's work.

Next questions:

I was thinking of renaming:

WITH_TQTGIF -> WITH_IMGFMT_GIF
WITH_JPEG -> WITH_IMGFMT_JPEG
WITH_PNG -> WITH_IMGFMT_PNG
WITH_LIBMNG -> WITH_IMGFMT_MNG

And adding corresponding plugin options:

BUILD_IMGFMT_PLUGIN_JPEG
BUILD_IMGFMT_PLUGIN_PNG
BUILD_IMGFMT_PLUGIN_MNG

WITH_IMGFMT_GIF will have no corresponding PLUGIN option and will be turned ON by default. Historically, it was optional only because of legal reasons which are no longer relevant.

Any objections?

Edit: fix `BUILD_IMGFMT_PLUGIN*` instead of `WITH_…`

There should be the same way as for SQL plugins × built-in module: If the plugin can be built as a separate library, so potentially independently with BUILD_LIB=OFF, then the option should be BUILD_IMGFMT_PLUGIN_....

If I remember well, there will also be a choise of whether to use a system library or a copy of the library contained in the code?

There should be the same way as for SQL plugins × built-in module: If the plugin can be built as a separate library, so potentially independently with BUILD_LIB=OFF, then the option should be BUILD_IMGFMT_PLUGIN_....

Yes, sure, I meant those... just mistyped... fixed in the previous comment..

If I remember well, there will also be a choise of whether to use a system library or a copy of the library contained in the code?

Yes, but I was going to drop support for those... IMHO there is very little reason in keeping outdated bundled copies when there are well-maintained versions in every distro...

ok, the plugins compilation should work now... no support for separate building of plugins yet though...

I've finished the rest of tools.

We don't need to build qconfig (an utility to configure TQt's build itself), right?

As there were no objections to LIBMNG -> MNG renaming, I assume this one is settled too.

Next one is: what to do about qplatformdefs.h? I assume we will generate our own, right?

This brings next question: Which platforms/architectures do we wish to support out of the box?

According to mkspecs currently tqmake supports following operating systems

aix bsdi cygwin darwin dgux dilos freebsd hpux hpuxi hurd irix linux lynxos macx netbsd openbsd qnx reliant sco solaris tru64 unixware win32

And compilers:

acc acc-32 acc-64 acc-o64 borland cc cc-64 cc-o32 cds cds-64 clang cxx ecc-64 g++ g++-32 g++34 g++-64 g++-sparc icc kcc kylix msvc msvc2005 msvc.net mwerks pbuilder pgcc watcom xlc xlc-64

I hope we can drop explicit support for platforms that are on a more weird side (at least unless there) like e.g. hpux-acc, right? What platforms have alive users, which we should focus on?

The obvious one are:

OS: linux freebsd
CCs: clang g++

Anything else?

I don't mind dropping some of the most uncommon/unused platforms and compilers, but if it doesn't take much to keep support, we should probably do that. In any case the list proposed above is too restrictive. cygwin, darwin, dilos, irix, netbsd, openbsd, solaris, win32 should be kept IMO.

It would be nice (one day...) to be able to build TQt3 for Windows.

In CMakeLists.txt there are a number of QT_INSTALL_ variables. Would be good to rename them to TQT_INSTALL_

Also there are individual BUILD option for each tutorial and example. Seems a bit overkill to me. I think a single BUILD_TUTORIALS and BUILD_EXAMPLES option would be more than fine. I doubt someone would build say tutorial 1,3,8-10 and not build the others...

As for platforms, in regards to generating qplatformdefs.h, I've looked trough those and it's impossible to write a robust one without actually testing it on an actual platform. But I believe I found a nice solution: by default we will generate (or at least pretend that we are "generating" it) a file (e.g. mkspec/local/qplatformdefs.h) for platforms we could actually test on, and at the same time we will provide a cmake option to choose one of the preexisting one if the generated one doesn't fit user's needs.

The current linux's one should nicely fit both: all modern glibc-based flavors of linux and modern FreeBSD. Are there any other platforms people can actually test it on?

It would be nice (one day...) to be able to build TQt3 for Windows.

This will require much more than just a platform file generation. We have better chances to compile for mac or embedded targets.

Also there are individual BUILD option for each tutorial and example. Seems a bit overkill to me. I think a single BUILD_TUTORIALS and BUILD_EXAMPLES option would be more than fine. I doubt someone would build say tutorial 1,3,8-10 and not build the others...

Agreed. Besides the current situation will make it difficult to choose which examples should be built based upon selected modules.

At the same time I believe we would like to add individual build options for tools: a lot more people will care for tquic, when for tqvfb or even tqassistant...

In CMakeLists.txt there are a number of QT_INSTALL_ variables. Would be good to rename them to TQT_INSTALL_

Both qmake and ./configure-based tqt source code still uses QT_* variations. This is an issue of general Qt->TQt rebranding and TQt integration, rather than cmake conversion's one...

Are there any other platforms people can actually test it on?

Just linux amd64 from my side. I believe Slavek has FreeBSD and Arch builds, plus a number of different architectures.

It would be nice (one day...) to be able to build TQt3 for Windows.

This will require much more than just a platform file generation.

Indeed, that's why I added "one day" 😉

At the same time I believe we would like to add individual build options for tools: a lot more people will care for tquic, when for tqvfb or even tqassistant...

Yes, this makes sense.

Both qmake and ./configure-based tqt source code still uses QT_* variations. This is an issue of general Qt->TQt rebranding and TQt integration, rather than cmake conversion's one...

Ok, we can address this one separately.

In the last few days I have been very busy with other activities, so I respond with a delay.

As for platforms, in regards to generating qplatformdefs.h, I've looked trough those and it's impossible to write a robust one without actually testing it on an actual platform. But I believe I found a nice solution: by default we will generate (or at least pretend that we are "generating" it) a file (e.g. mkspec/local/qplatformdefs.h) for platforms we could actually test on, and at the same time we will provide a cmake option to choose one of the preexisting one if the generated one doesn't fit user's needs.

Yes, I intended to do it in the same way – for CMake building to generate qplatformdefs.h according to the current platform. I assume that it will currently cover all the platforms for which we are building. And later we can deal with how to deal with the original mkspecs.

The current linux's one should nicely fit both: all modern glibc-based flavors of linux and modern FreeBSD. Are there any other platforms people can actually test it on?

I believe that @obache may build for some other BSDs and other Unix systems. I assume that even for these other systems it should be possible to use an automatically generated qplatformdefs.h.

It would be nice (one day...) to be able to build TQt3 for Windows.

This will require much more than just a platform file generation. We have better chances to compile for mac or embedded targets.

We want to leave the door open for all variants. It is clear that it will not be available immediately, but if there is someone who is interested and contributors, it will be great to make it possible.

Also there are individual BUILD option for each tutorial and example. Seems a bit overkill to me. I think a single BUILD_TUTORIALS and BUILD_EXAMPLES option would be more than fine. I doubt someone would build say tutorial 1,3,8-10 and not build the others...

Agreed. Besides the current situation will make it difficult to choose which examples should be built based upon selected modules.

At the same time I believe we would like to add individual build options for tools: a lot more people will care for tquic, when for tqvfb or even tqassistant...

Yes, here it will certainly be useful to make options to build individual tools. The usefulness of the options for building individual tutorials and examples could probably be doubted.

There it would probably be useful to prepare CMakeLists.txt so, that every example and tutorial was ready for the building completely separately. So that they can be built independently of the rest if necessary.

In CMakeLists.txt there are a number of QT_INSTALL_ variables. Would be good to rename them to TQT_INSTALL_

Both qmake and ./configure-based tqt source code still uses QT_* variations. This is an issue of general Qt->TQt rebranding and TQt integration, rather than cmake conversion's one...

Yes, renaming is still ongoing and is independent of CMake conversion.

In the last few days I have been very busy with other activities, so I respond with a delay. > As for platforms, in regards to generating `qplatformdefs.h`, I've looked trough those and it's impossible to write a robust one without actually testing it on an actual platform. But I believe I found a nice solution: by default we will generate (or at least pretend that we are "generating" it) a file (e.g. `mkspec/local/qplatformdefs.h`) for platforms we could actually test on, and at the same time we will provide a cmake option to choose one of the preexisting one if the generated one doesn't fit user's needs. > Yes, I intended to do it in the same way – for CMake building to generate `qplatformdefs.h` according to the current platform. I assume that it will currently cover all the platforms for which we are building. And later we can deal with how to deal with the original mkspecs. > The current linux's one should nicely fit both: all modern glibc-based flavors of linux and modern FreeBSD. Are there any other platforms people can actually test it on? > I believe that @obache may build for some other BSDs and other Unix systems. I assume that even for these other systems it should be possible to use an automatically generated `qplatformdefs.h`. > >It would be nice (one day...) to be able to build TQt3 for Windows. > > This will require much more than just a platform file generation. We have better chances to compile for mac or embedded targets. > We want to leave the door open for all variants. It is clear that it will not be available immediately, but if there is someone who is interested and contributors, it will be great to make it possible. > > Also there are individual BUILD option for each tutorial and example. Seems a bit overkill to me. I think a single BUILD_TUTORIALS and BUILD_EXAMPLES option would be more than fine. I doubt someone would build say tutorial 1,3,8-10 and not build the others... > > Agreed. Besides the current situation will make it difficult to choose which examples should be built based upon selected modules. > > At the same time I believe we would like to add individual build options for tools: a lot more people will care for tquic, when for tqvfb or even tqassistant... > Yes, here it will certainly be useful to make options to build individual tools. The usefulness of the options for building individual tutorials and examples could probably be doubted. There it would probably be useful to prepare CMakeLists.txt so, that every example and tutorial was ready for the building completely separately. So that they can be built independently of the rest if necessary. > > In CMakeLists.txt there are a number of QT_INSTALL_ variables. Would be good to rename them to TQT_INSTALL_ > > Both qmake and ./configure-based tqt source code still uses `QT_*` variations. This is an issue of general Qt->TQt rebranding and TQt integration, rather than cmake conversion's one... Yes, renaming is still ongoing and is independent of CMake conversion.

There it would probably be useful to prepare CMakeLists.txt so, that every example and tutorial was ready for the building completely separately. So that they can be built independently of the rest if necessary.

It's on the list already:

Self-contained build for examples/tutorials i.e. you should be to cp examples/aclock /tmp && cd /tmp/aclock && cmake . && make

but it (as well as the separate build of plugin/tools) will probably have to wait till the tqtinterface merge finished as we will have to make some changes to FindTQt to some extent as now it's a bit messy...

I believe that @obache may build for some other BSDs and other Unix systems. I assume that even for these other systems it should be possible to use an automatically generated qplatformdefs.h.

It seems most modern BSD's and linux's flavors of qplatformdefs.h are pretty much identical... I suppose we may have some troubles with solaris-derived (There were mention of irix in the neighboring WIP PR) platforms and some very old (pre-FreeBSD-4.0 old) BSD's...