Menu
▾
▴
rosegarden-devel
|
From: D. M. M. <ros...@gm...> - 2008-09-15 19:35:15
|
I'm getting different results between building with the CMake-generated Makefile and building with qt4-makefile. For instance, with plain make (using Makefile) I get: /home/me/SVN/qt4/src/document/io/HydrogenXMLHandler.cpp: In member function ‘virtual bool Rosegarden::HydrogenXMLHandler::endElement(const QString&, const QString&, const QString&)’: /home/silvan/SVN/qt4/src/document/io/HydrogenXMLHandler.cpp:223: error: no match for ‘operator<<’ in ‘((QDebug*)((QDebug*)((QDebug*)((QDebug*)((QDebug*) ((QDebug*)kdDebug(int)().QDebug::operator<<(((const char*)"HydrogenXMLHandler::endElement - Hydrogen Instrument : id = ")))->QDebug::operator<<(((Rosegarden::HydrogenXMLHandler*)this)->Rosegarden::HydrogenXMLHandler::m_id))->QDebug::operator<<(((const char*)", muted = ")))->QDebug::operator<<(((int) ((Rosegarden::HydrogenXMLHandler*)this)->Rosegarden::HydrogenXMLHandler::m_muted)))->QDebug::operator<<(((const char*)", volume = ")))->QDebug::operator<<(((Rosegarden::HydrogenXMLHandler*)this)->Rosegarden::HydrogenXMLHandler::m_instrumentVolumes.std::vector<_Tp, _Alloc>::operator[] [with _Tp = double, _Alloc = std::allocator<double>] (((unsigned int) ((Rosegarden::HydrogenXMLHandler*)this)->Rosegarden::HydrogenXMLHandler::m_instrument))))->QDebug::operator<<(((const char*)", filename = \"")) << ((Rosegarden::HydrogenXMLHandler*)this)->Rosegarden::HydrogenXMLHandler::m_fileName’ compilation terminated due to -Wfatal-errors. But: $ make -f qt4-makefile src/document/io/HydrogenXMLHandler.o /usr/bin/c++ -c -DQT3_SUPPORT -Wall -O0 -g -DHAVE_ALSA -DHAVE_LIBJACK -DHAVE_DSSI -DHAVE_LADSPA -DHAVE_LIBLO -DHAVE_LIBLRDF -DHAVE_XFT -DDEBUG -D'VERSION="2.0-yeah-whatever-innit"' -I/usr/include/qt4/Qt3Support -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui -I/usr/include/qt4/QtXml -I/usr/include/qt4/QtNetwork -I/usr/include/qt4 -I/usr/lib/kde4/include -I/usr/include -I/usr/local/include -I/usr/include/freetype2 -Isrc/base -Isrc src/document/io/HydrogenXMLHandler.cpp -o src/document/io/HydrogenXMLHandler.o So at a glance, it appears building with qt4-makefile gets around all these problems with QDebug operator errors that are breaking the build with the CMake-generated Makefile. I'm not sure what to make of any of that. I looked into QDebug, and it doesn't actually seem to exist. It's not listed in the Qt 4.0 API at all, and the closest thing I can find is qDebug() in QtGlobal. It looks like maybe a broken Qt4 conversion, but when I searched my bugs list folder for clues (it goes back for years) I couldn't find anything in any commits from this generation at all. I'm thoroughly and hopelessly bumfuzzled. Urf. -- D. Michael McIntyre |
|
From: Julie S <msj...@ya...> - 2008-09-16 04:04:56
|
Dear Michael,
You wrote:
> So at a glance, it appears building with qt4-makefile gets
> around all these
> problems with QDebug operator errors that are breaking the
> build with the
> CMake-generated Makefile.
I have to admit, I've just left c-make alone. I've been using the qt4-makefile.
I'll switch, if needed, but my computer is so slow, that I just didn't want to spend the time compiling multiple ways. Also I have all of my shortcuts setup already using qt4-makefile.
On my end I thought I got the "<< operator" stuff, but I will look that over today.
My vehicle is in the repair shop so, I am home for the day.
Take care.
Sincerely,
Julie S.
|
|
From: <li...@dw...> - 2008-09-16 13:17:08
|
On Tuesday 16 September 2008 03:35:10 D. Michael McIntyre wrote: > I'm getting different results between building with the CMake-generated > Makefile and building with qt4-makefile. I'm glad it's not just me then... I've resorted to commenting them out. > I'm not sure what to make of any of that. I looked into QDebug, and it > doesn't actually seem to exist. It's not listed in the Qt 4.0 API at all, > and the closest thing I can find is qDebug() in QtGlobal. > > It looks like maybe a broken Qt4 conversion, but when I searched my bugs > list folder for clues (it goes back for years) I couldn't find anything in > any commits from this generation at all. I'll have a look at this and see what I can find. David |
|
From: Chris C. <ca...@al...> - 2008-09-16 14:09:36
|
On Tue, Sep 16, 2008 at 3:35 AM, D. Michael McIntyre <ros...@gm...> wrote: > I'm getting different results between building with the CMake-generated > Makefile and building with qt4-makefile. > > For instance, with plain make (using Makefile) I get: > [ big complicated load of crap ] > > But: > > $ make -f qt4-makefile src/document/io/HydrogenXMLHandler.o > [ nice sensible successful build report ] This is a code problem, not a build system problem. The default build with CMake uses -DNDEBUG, for a "release" build; qt4-makefile does a debug build. Our code in misc/Debug.h that sets up no-op debug streams in the no-debug case does not appear to work with KDE4. It's mostly garbage, but it should be salvageable garbage without having to rewrite all our code -- we can fix it in Debug.h. The weird thing is that... > [...] I looked into QDebug, and it > doesn't actually seem to exist. It's not listed in the Qt 4.0 API at all, > and the closest thing I can find is qDebug() in QtGlobal. Right -- the class _does_ exist in the QtCore library; the header is there if you look for it. But it's totally undocumented. Is it new? Is it something we aren't supposed to use? The debug build does work, and that's the one that really needs to use QDebug, so there probably isn't a serious problem here. We just need to frig the #defines so that the no-op no-debug case also builds. Chris |
|
From: Chris C. <ca...@al...> - 2008-09-16 14:14:30
|
btw, the new CMake doesn't appear to configure for me. I get this error: CMake Error: Error in cmake code at /work/rosegarden/build/qt4/cmake_admin/FindQt4.cmake:1306: INCLUDE Could not find include file: FindPackageMessage Current CMake stack: [2]/work/rosegarden/build/qt4/cmake_admin/FindQt4.cmake [1]/work/rosegarden/build/qt4/CMakeLists.txt CMake Error: Error in cmake code at /work/rosegarden/build/qt4/cmake_admin/FindQt4.cmake:1307: Unknown CMake command "FIND_PACKAGE_MESSAGE". I really haven't looked into this at all, though -- this is the first time I've ever tried to run it (I only did so because of the previous debug problem, I've been sticking with qt4-makefile so far for simplicity) and I'm just about to go to bed, so I'm probably being most unhelpful even mentioning it. Chris |
|
From: Emanuel R. <xb...@we...> - 2008-09-16 14:54:37
|
2008/9/16 Chris Cannam <ca...@al...>: > btw, the new CMake doesn't appear to configure for me. I get this error: > > CMake Error: Error in cmake code at > /work/rosegarden/build/qt4/cmake_admin/FindQt4.cmake:1306: > INCLUDE Could not find include file: FindPackageMessage > Current CMake stack: > [2]/work/rosegarden/build/qt4/cmake_admin/FindQt4.cmake > [1]/work/rosegarden/build/qt4/CMakeLists.txt > > CMake Error: Error in cmake code at > /work/rosegarden/build/qt4/cmake_admin/FindQt4.cmake:1307: > Unknown CMake command "FIND_PACKAGE_MESSAGE". > > I really haven't looked into this at all, though -- this is the first > time I've ever tried to run it (I only did so because of the previous > debug problem, I've been sticking with qt4-makefile so far for > simplicity) and I'm just about to go to bed, so I'm probably being > most unhelpful even mentioning it. > copy /usr/share/cmake-2.6/Modules/FindPackageMessage.cmake to cmake_admin directory, or add /usr/share/cmake-2.6/Modules/ to cmake search path (can't tell you how) have a good night |
|
From: <li...@dw...> - 2008-09-16 15:05:12
|
On Tuesday 16 September 2008 22:09:32 Chris Cannam wrote: > This is a code problem, not a build system problem. > > The default build with CMake uses -DNDEBUG, for a "release" build; > qt4-makefile does a debug build. Our code in misc/Debug.h that sets > up no-op debug streams in the no-debug case does not appear to work > with KDE4. I had a look at this in Eclipse and noticed that the section in misc/Debug.h for NDEBUG defined is greyed out. This is in spite of the fact that the CMake geenrated makefile is supposed to be for the default release build. Anyway, I've managed to get the whole of RosegardenSequencer to build now with a few tweaks to the SEQUENCER_DEBUG lines: this amounted to converting all RealTime instances to const char* via toString().c_str(). Admittedly this is with no audio or plugin support whatsoever... David |
|
From: Emanuel R. <xb...@we...> - 2008-09-21 16:58:02
|
I just noticed: By fixing RosegardenTransport in the cmake build, I did not solve it in the qt4-make build. the cmake prepends a "ui_" to the moc-qt4 generated headerfile: ui_RosegardenTransport.h The cmake seems to compile further and I think it's what we will use at the end, so I currently prefere using the cmake build. Is that ok, or should we better use the same makefile ? |
|
From: Chris C. <ca...@al...> - 2008-09-22 10:43:56
|
On Tue, Sep 16, 2008 at 10:54 PM, Emanuel Rumpf <xb...@we...> wrote: > 2008/9/16 Chris Cannam <ca...@al...>: >> btw, the new CMake doesn't appear to configure for me. I get this error: >> >> CMake Error: Error in cmake code at >> /work/rosegarden/build/qt4/cmake_admin/FindQt4.cmake:1306: >> INCLUDE Could not find include file: FindPackageMessage >> Current CMake stack: >> [2]/work/rosegarden/build/qt4/cmake_admin/FindQt4.cmake >> [1]/work/rosegarden/build/qt4/CMakeLists.txt >> >> CMake Error: Error in cmake code at >> /work/rosegarden/build/qt4/cmake_admin/FindQt4.cmake:1307: >> Unknown CMake command "FIND_PACKAGE_MESSAGE". > > copy > /usr/share/cmake-2.6/Modules/FindPackageMessage.cmake > to cmake_admin directory, > or add /usr/share/cmake-2.6/Modules/ to cmake search path (can't tell you how) Ah. I don't have CMake 2.6, only CMake 2.4 which seems to be latest version packaged for Ubuntu. And that has no FindPackageMessage.cmake file. Is CMake 2.6 now effectively required, or is this a trivial thing to work around? I'm aware that CMake is very easy to install from the official packages, so I don't mind if I do have to upgrade, but I'd quite like to check this first. Chris |
|
From: Chris C. <ca...@al...> - 2008-09-22 18:45:01
|
On Mon, Sep 22, 2008 at 3:05 PM, Emanuel Rumpf <xb...@we...> wrote: > 2008/9/22 Chris Cannam <ca...@al...>: >> Is CMake 2.6 now effectively required, or is this a trivial thing to >> work around? > > I don't know. > Maybe it is enough to put FindPackageMessage.cmake > into the cmake_admin directory. > I send it to you, so you can test it. [back on list] Nope, doesn't work. (But thanks.) CMake pukes on the first occurrence of the word FUNCTION, so it looks like there must have been some pretty big changes somewhere. I take it we need 2.6, then. Chris |
|
From: <li...@dw...> - 2008-09-22 20:34:31
|
On Monday 22 September 2008 19:16:14 Chris Cannam wrote: > On Mon, Sep 22, 2008 at 3:05 PM, Emanuel Rumpf <xb...@we...> wrote: > > 2008/9/22 Chris Cannam <ca...@al...>: > >> Is CMake 2.6 now effectively required, or is this a trivial thing to > >> work around? > > > > I don't know. > > Maybe it is enough to put FindPackageMessage.cmake > > into the cmake_admin directory. > > I send it to you, so you can test it. > > [back on list] > > Nope, doesn't work. (But thanks.) CMake pukes on the first > occurrence of the word FUNCTION, so it looks like there must have been > some pretty big changes somewhere. > > I take it we need 2.6, then. I see that CMakeLists.txt has the minimum required CMake version set to 2.4.2. Guess we should change that to 2.6... David |
|
From: D. M. M. <ros...@gm...> - 2008-09-23 01:53:44
|
On Monday 22 September 2008, Chris Cannam wrote: > Ah. I don't have CMake 2.6, only CMake 2.4 which seems to be latest > version packaged for Ubuntu. You can get it as a backport. -- D. Michael McIntyre |
|
From: Chris C. <ca...@al...> - 2008-09-23 09:40:45
|
On Tue, Sep 23, 2008 at 2:53 AM, D. Michael McIntyre <ros...@gm...> wrote: > On Monday 22 September 2008, Chris Cannam wrote: >> Ah. I don't have CMake 2.6, only CMake 2.4 which seems to be latest >> version packaged for Ubuntu. > > You can get it as a backport. I actually wouldn't know how. (googles) Ah, I see. Well, it's as simple to get from the cmake site and I'm not sure I want to complicate my system with more new stuff than I have to, so I'll stick with the official distribution for now. After installing cmake 2.6 and setting the path for kde4-config (which it didn't find in ubuntu's weird location), it configured OK -- trying the build now. Chris |
Thanks for helping keep SourceForge clean.
X