oddity
10th May 2013, 16:45
My employer has recently purchased a code base for a C/C++ application running on SUSE Linux (11).
It includes about 20 modules, most of which use Qt4 extensively, and will continue to do so--there are no plans to upgrade to Qt5.
The package as a whole is built using Autotools, with each module that uses Qt including in its automake input file (Makefile.am) fragmentary "pre" and "post" input files (qt_pre.am, qt_post.am, qt_postui.am) which contain the rules used to invoke moc, uic, and rcc as separate tools, as needed. This approach does work, and it is expected we will continue to use it for the foreseeable future.
It is also expected that we will continue to use Eclipse as our development IDE (able to build the package as an Autotools project), rather than switching to Qt Creator.
There are seven modules in this entire bundle of code, which include .pro files. Five of them were created using qmake back in 2003, two appear to be hand-carved about the same time. I haven't seen anything to suggest these are used at all, when the moc, uic, and rcc tools are run as part of the Autotools build, so it may be they are obsolete...or not, I don't have the experience to tell, yet. We're looking to clarify this with the company we bought the code from, but this may take a while.
In the meantime, I am investigating what we need to do, to internationalize the package. I'm fine with the basics of Qt internationalization, using lupdate, Qt Linguist, lrelease, and so on, and the Qt code appears to be fine in terms of tr() being used to wrap all the texts we need to translate.
My first question is: in a build world which is not using qmake at all, and where I do not have the .pro file I would normally expect to create at the top of the /src tree, in which to place my TRANSLATIONS += specifier...if I run qmake -project from the top of that /src tree in order to create that file for use with lupdate and lrelease, is this likely to run into any problems because of the scattering of .pro files lower in the tree? Can the two layers of .pro files co-exist?
Second, I'm assuming that, as the /src-level .pro file I propose to create will not be referenced anywhere in build rules, its mere presence should not create any problems when the Autotools build invokes moc, uic, and rcc. Is this reasonable, or wrong-headed?
It includes about 20 modules, most of which use Qt4 extensively, and will continue to do so--there are no plans to upgrade to Qt5.
The package as a whole is built using Autotools, with each module that uses Qt including in its automake input file (Makefile.am) fragmentary "pre" and "post" input files (qt_pre.am, qt_post.am, qt_postui.am) which contain the rules used to invoke moc, uic, and rcc as separate tools, as needed. This approach does work, and it is expected we will continue to use it for the foreseeable future.
It is also expected that we will continue to use Eclipse as our development IDE (able to build the package as an Autotools project), rather than switching to Qt Creator.
There are seven modules in this entire bundle of code, which include .pro files. Five of them were created using qmake back in 2003, two appear to be hand-carved about the same time. I haven't seen anything to suggest these are used at all, when the moc, uic, and rcc tools are run as part of the Autotools build, so it may be they are obsolete...or not, I don't have the experience to tell, yet. We're looking to clarify this with the company we bought the code from, but this may take a while.
In the meantime, I am investigating what we need to do, to internationalize the package. I'm fine with the basics of Qt internationalization, using lupdate, Qt Linguist, lrelease, and so on, and the Qt code appears to be fine in terms of tr() being used to wrap all the texts we need to translate.
My first question is: in a build world which is not using qmake at all, and where I do not have the .pro file I would normally expect to create at the top of the /src tree, in which to place my TRANSLATIONS += specifier...if I run qmake -project from the top of that /src tree in order to create that file for use with lupdate and lrelease, is this likely to run into any problems because of the scattering of .pro files lower in the tree? Can the two layers of .pro files co-exist?
Second, I'm assuming that, as the /src-level .pro file I propose to create will not be referenced anywhere in build rules, its mere presence should not create any problems when the Autotools build invokes moc, uic, and rcc. Is this reasonable, or wrong-headed?