cmake EXEC_PROGRAM merges stdout and stderr?

[Alexander Neundorf]

Hi,

On Friday 03 February 2006 15:55, David Faure wrote:
> On Friday 03 February 2006 15:36, Brad King wrote:
> > David Faure wrote:
> > > This warning line should obviously not be there. It's a warning by
> > > uic3, send to stderr.
...
> Thanks for the info, but in practical terms, does this mean there is no way
> to fix this problem without changing cmake itself?
> Is there maybe something else than EXEC_PROGRAM (or something else than
> OUTPUT_VARIABLE) which we can use to run a command and put its output into
> a file?
> I guess adding " > foo.h" to the command won't work since there's probably
> no shell involved...

We could simply let uic output the data into a temporary file and then work on 
the temporary file.
I didn't try, but maybe a " 2> /dev/null" might work, but probably won't work 
on windows.
We could use perl or sed like the "old" buildsystem does to do the 
replacements.
I tried to implement everything within cmake, without any external tools 
required (except the perl scripts which are used to create hashtables etc.).
The workaround were some regexps which remove the uic3 error messages (this is 
probably the most ugly workaround which was required to build kdelibs/ ).

I already had email exchange with Brad King and Bill Hoffman about this issue. 
To change the behaviour of exec_program(), cmake code itself has to be 
changed. Bill is this week on vacation, otherwise he might already have done 
something.

To get things straight, here's a list of missing features/bugs in the cmake 
KDE release:

get_filename_component( ABS_PATH) doesn't work, workaround is 
qt4_get_abs_path(). This is fixed in current cmake cvs.

It doesn't bootstrap with mingw (but is able to create makefiles for mingw). 
This is fixed in current cmake cvs.

For checking whether MSVC is used one has to use CMAKE_CXX_COMPILER. A 
three-line-workaround which defines MSVC is in FindKDE4.cmake. It's on the 
todo of the cmake devs to move this into cmake. 

add_custom_command() always executes the given program in the current 
directory. Workaround: use CMAKE_COMMAND, see kdelibs/kabc/CMakeLists.txt. 
It's on the todo of the cmake developers.

exec_program() captures both stdout and stderr in one variable. The cmake devs 
know about, see above.

The install_foo() commands could use some more features like creating symlinks 
(can be worked around), setting permissions, installing to absolute paths 
(can be worked around) and support for make uninstall has to be added 
explicitely. There's a bug report in the cmake bugtracker which collects all 
the various wishes.

So, I think that's all, and none of them was a real problem for building 
kdelibs/.

Bye
Alex
-- 
Work: alexander.neundorf AT jenoptik.com - http://www.jenoptik-los.de
Home: neundorf AT kde.org                - http://www.kde.org
      alex AT neundorf.net               - http://www.neundorf.net