View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0007433CMakeCMakepublic2008-07-31 08:302008-09-30 18:28
Reportertanguy_k 
Assigned ToClinton Stimpson 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionCMake-2-6 
Target VersionFixed in Version 
Summary0007433: FindQt4.cmake: lupdate can produce a too long input
DescriptionInside FindQt4.cmake, macro QT4_CREATE_TRANSLATION

In some cases (too many sources), the lupdate command line can be too long and MinGW (or nmake if the input line is even longer) produce the error: "The input line is too long"

Solution: write a temporary .pro file with all the sources inside

Patch attached
TagsNo tags attached.
Attached Filesdiff file icon FindQt4_lupdate_toolong.diff [^] (1,312 bytes) 2008-07-31 08:30 [Show Content]

 Relationships

  Notes
(0013002)
tanguy_k (reporter)
2008-08-13 14:47

I found a little problem with my patch: there no dependency between the .ts files and the generated .pro file
(0013245)
Clinton Stimpson (developer)
2008-08-30 09:41

How about just listing the directories that contain your source files from which the translations are made.

I added that to the documentation.

/cvsroot/CMake/CMake/Modules/FindQt4.cmake,v <-- FindQt4.cmake
new revision: 1.131; previous revision: 1.130

Does that solve your problem? Then there's no dependency problem by introducing a .pro file.
(0013505)
tanguy_k (reporter)
2008-09-18 01:19

It solves (partly) the problem.
I would suggest to add even more documentation about that inside FindQt4.cmake
lupdate has the capacity to scan the directories provided using a default list of extensions and this is the kind of feature that is not obvious and worth to be mention.

Anyway,

My current problem now is that calling qt4_create_translation() erases my *.ts files at the end of the Makefile generation (i.e at the end of the cmake command, not the make command)!!! (and then re-generate them properly after)

So if you have any hint where to look at inside the generated Makefiles...
(I'm using WinXP CMake-2.6.1 + latest FindQt4.cmake from CVS)
(0013513)
Clinton Stimpson (developer)
2008-09-18 10:57

/cvsroot/CMake/CMake/Modules/FindQt4.cmake,v <-- FindQt4.cmake
new revision: 1.132; previous revision: 1.131
More docs added, and add ability to specify extra arguments to lupdate such as -extensions for directory scans.

I'm unable to reproduce that problem of cmake erasing the ts files.
Even the timestamp of the .ts files don't change when I run cmake, which is what I expect.
(0013532)
tanguy_k (reporter)
2008-09-20 11:37

I've just erased my build directory and my .ts files are not deleted anymore, stange bug...

Current problem now is that .ts files don't get updated via lupdate and I think the reason is pretty simple:

if I give directories to QT4_CREATE_TRANSLATION
then the lupdate command depends on directories instead of files (.cpp, .c...)
Directories break the dependency chain since they can't be "modified" and thus CMake does not run lupdate.
(0013533)
Clinton Stimpson (developer)
2008-09-20 15:01

Here's an example:

    ...
    SET(CMAKE_GUI_LANGUAGES cz)
    SET(TS_FILES)
    FOREACH(LANG ${CMAKE_GUI_LANGUAGES})
      SET(TS_FILES ${TS_FILES} "${CMAKE_CURRENT_SOURCE_DIR}/cmake_${LANG}.ts")
    ENDFOREACH(LANG)
    QT4_CREATE_TRANSLATION(QM_FILES ${CMAKE_CURRENT_SOURCE_DIR} ${TS_FILES})
    ADD_CUSTOM_COMMAND(OUTPUT ${TS_FILES} DEPENDS ${SRCS} APPEND)
    SET(SRCS ${SRCS} ${QM_FILES})
    ...

The extra ADD_CUSTOM_COMMAND to add dependencies takes care of your problem.
(0013534)
tanguy_k (reporter)
2008-09-20 23:43
edited on: 2008-09-20 23:48

Thanks for the ADD_CUSTOM_COMMAND(OUTPUT...), I didn't know how to write this.

So I've managed to make everything work for my project. I got again the "*.ts files erased bug" during my testing, I still don't know why and again a new "delete build dir" fixed it :/

Here is what I wrote to make everything work:

set(TS_FILES
    "${CMAKE_CURRENT_SOURCE_DIR}/translations/quarkplayer_fr.ts"
    "${CMAKE_CURRENT_SOURCE_DIR}/translations/quarkplayer_de.ts"
    "${CMAKE_CURRENT_SOURCE_DIR}/translations/quarkplayer_es.ts"
)

#"${CMAKE_CURRENT_SOURCE_DIR}/..." is important otherwise
#it won't work since qt4_create_translation() uses absolute path for *.ts files.

set(QM_FILES "")
qt4_create_translation(QM_FILES ${DIRS_TRANSLATIONS} ${TS_FILES})
add_custom_command(OUTPUT ${TS_FILES} DEPENDS ${SRCS_TRANSLATIONS} APPEND)
add_executable(quarkplayer ${quarkplayer_SRCS} ${QM_FILES})
install(FILES ${QM_FILES} DESTINATION ${BIN_INSTALL_DIR}/translations)


From my point of vue, even if the "directories lupdate approach" works, I still prefer the ".pro lupdate approach" used by my patch, here the reasons:

- You have to keep track of the directories and sources to be translated instead of just the sources.

To keep track of the directories are not that simple since you have the CMAKE_SOURCE_DIR + CMAKE_BINARY_DIR (for the generated ui_*.h files if any)

If you have plugins, libraries... containing translations that need to be integrated in your project, it adds complexity and I had to wrote this in order to avoid it: http://code.google.com/p/phonon-vlc-mplayer/source/browse/trunk/cmake/AddQtTranslations.cmake?r=493 [^] instead of a stupid global variable that just keeps track of the source files to be translated.

- You have to take care of a new dependency rule (add_custom_command(OUTPUT ${TS_FILES}...)
This is just one line but still, I had to re-read my code before to find out that set(TS_FILES translations/quarkplayer_fr.ts) should be written set(TS_FILES "${CMAKE_CURRENT_SOURCE_DIR}/translations/quarkplayer_fr.ts")


I'm 100% sure that other users will get the "The input line is too long" error and will have to switch to another approach and eventually modify their code.
By using the ".pro lupdate approach", no need to change code, complexity is hidden and there is no risk for users to get the "input error". I'm pretty sure this can save some time to them.

What do you think?

(0013547)
Clinton Stimpson (developer)
2008-09-22 15:02

It makes a .pro file now. And it seems to work fine. Can you verify?

/cvsroot/CMake/CMake/Modules/FindQt4.cmake,v <-- FindQt4.cmake
new revision: 1.134; previous revision: 1.133

Also, I didn't think you needed to run lupdate with the ui_*.h files or the moc files. Running it on the .ui files was enough for me, and made more sense.

 Issue History
Date Modified Username Field Change
2008-07-31 08:30 tanguy_k New Issue
2008-07-31 08:30 tanguy_k File Added: FindQt4_lupdate_toolong.diff
2008-07-31 13:08 Bill Hoffman Status new => assigned
2008-07-31 13:08 Bill Hoffman Assigned To => Clinton Stimpson
2008-08-13 14:47 tanguy_k Note Added: 0013002
2008-08-30 09:41 Clinton Stimpson Note Added: 0013245
2008-09-18 01:19 tanguy_k Note Added: 0013505
2008-09-18 10:57 Clinton Stimpson Note Added: 0013513
2008-09-20 11:37 tanguy_k Note Added: 0013532
2008-09-20 15:01 Clinton Stimpson Note Added: 0013533
2008-09-20 23:43 tanguy_k Note Added: 0013534
2008-09-20 23:48 tanguy_k Note Edited: 0013534
2008-09-22 15:02 Clinton Stimpson Status assigned => resolved
2008-09-22 15:02 Clinton Stimpson Resolution open => fixed
2008-09-22 15:02 Clinton Stimpson Note Added: 0013547
2008-09-30 18:28 Clinton Stimpson Status resolved => closed


Copyright © 2000 - 2018 MantisBT Team