MainWindow.cpp - Build fails on Apple

[tresf]

@lukas-w, not sure if this is related to some refactoring, some namespace issues, or what, but wanted to do some early 1.2 build testing on Apple to prepare for the eventual RC1.

[ 13%] Building CXX object src/CMakeFiles/lmms.dir/gui/MainWindow.cpp.o
/Users/tresf/lmms/src/gui/MainWindow.cpp:533:25: error: no matching constructor
      for initialization of 'QList<QWidget *>'
        for (QWidget* widget : QList<QWidget*>{
                               ^              ~
/opt/local/include/QtCore/qlist.h:121:12: note: candidate constructor not
      viable: requires 0 arguments, but 4 were provided
    inline QList() : d(&QListData::shared_null) { d->ref.ref(); }
           ^
/opt/local/include/QtCore/qlist.h:122:12: note: candidate constructor not
      viable: requires single argument 'l', but 4 arguments were provided
    inline QList(const QList<T> &l) : d(l.d) { d->ref.ref(); if...
           ^
1 error generated.
make[2]: *** [src/CMakeFiles/lmms.dir/gui/MainWindow.cpp.o] Error 1
make[1]: *** [src/CMakeFiles/lmms.dir/all] Error 2
make: *** [all] Error 2

[tresf]

Ok, this looks like a compatibility issues with the initializer list and Clang. We should remove the shortcut code for compat.

http://stackoverflow.com/questions/10991274/initializer-list-in-clang

[tresf]

Proposal:

        // Add editor subwindows
        QList<QWidget*> widgets;
        widgets.append(gui->automationEditor());
        widgets.append(gui->getBBEditor());
        widgets.append(gui->pianoRoll());
        widgets.append(gui->songEditor());
        for (QWidget* widget : widgets)
        {
                QMdiSubWindow* window = workspace()->addSubWindow(widget);
                window->setWindowIcon(widget->windowIcon());
                window->setAttribute(Qt::WA_DeleteOnClose, false);
                window->resize(widget->sizeHint());
        }

(alternately you could move this to gui() class and generate this list internally and do for (QWidget* widget : gui()->getWidgets()) { ... })

[lukas-w]

Clang supports initializer lists as of 3.1. Try changing

QList<QWidget*>{…,…}

to

QList<QWidget*>({…,…})

(putting parentheses around the initializer list)

[tresf]

@lukas-w, I tried that last night and again just now for sanity's sake... No dice here...

[lukas-w]

Hm… What Qt version are you using? I just saw in the Qt docs that QList's constructor supports initializer_list since Qt 4.8, but I wonder why Travis (Qt 4.6) isn't failing there if that's the case.

[lukas-w]

Ah scratch that, Travis has Qt 4.8.

[tresf]

As linked in the article, I think it's a language standard that needs to be enabled in Clang. I don't know much about these, but since it compiles fine otherwise, I don't see the harm in splitting this out. 👯

[tresf]

Specifically, the part that says:

clang++ -stdlib=libc++ -std=c++0x foo.cpp

That might help here... I started looking into these standards when fixing SWH plugins and my mind exploded.

[lukas-w]

a language standard that needs to be enabled in Clang.

That'd be --std=c++0x, but that should already be enabled in our CMakeLists.txt.

So you're using Qt 4.8? If not, that's most likely the cause of this issue.

[lukas-w]

I don't know much about these, but since it compiles fine otherwise, I don't see the harm in splitting this out.

Well, initializer_list is a great addition of C++11, so I think it's important to know if the issue you're having is Qt or Clang related.

[tresf]

Well, initializer_list is a great addition of C++11, so I think it's important to know if the issue you're having is Qt or Clang related

4.8.6_0 according to macports.

[tresf]

According to what I'm reading, the -stdlib=libc++ is also needed, but adding it doesn't seem to help.

I started researching other places this might have been broken to no avail...

[lukas-w]

Take a look at https://trac.macports.org/changeset/102010

Apparently C++11 is not enabled in Macport's Qt by default.

[tresf]

Good find. (or bad find, given the impact). What do you recommend we do? I can do an #ifdef, but it seems meaningless to write redundant compat code in this instance.

[tresf]

... Also we can switch to Homebrew and hope they've fixed this, but I won't have time to do that for a few weeks at least.

[lukas-w]

Either we change that code to not use C++11 or you recompile Qt with C++11 support on your machine. The latter sounds a lot more time-consuming ;)

[tresf]

Either we change that code to not use C++11 or you recompile Qt with C++11 support on your machine. The latter sounds a lot more time-consuming ;)

Yes, and not just my machine... Any machine (such as Jonathan, or more likely, Travis).

-Tres

[lukas-w]

Fixed via c7e3ab3

[tresf]

@lukas-w I can confirm that Homebrew does not suffer from this bug. I'm working to move our building to Homebrew via #2271

[lukas-w]

Meant to write #2271?

[tresf]

Meant to write #2271?

👍