Nightly builds - 3.0

• Aug 18, 2017 - 14:11

Hi,
In my opinion, the best way to test a new version, is to produce new music in 3.0.

And i'm doing this for a long time.

However, i discovered many, many small bugs. What is the best option to report all bugs? This forum? Or do you have a special forum/email-addresss to report bugs in 3.0?

You are on the good way, 3.0 is fantastic in it's 'basics', and i want to help you to fix all bugs and problems i discover... The question is: what's the most efficient way?

Please let me know.

Theo.


Comments

First here in the Technology Forum (to make sure it isn't just a misunderstanding, or had been reported already), then in the issue tracker.

My personal view:

If you've got a lot of them to report at once, consider maybe a handful of forum posts with a few relates reports each. Then after discussion, submitting the relevant ones one at a time to the issue tracker.

I have noticed the windows MingW build seems to be very crashy... but I have only just loaded the environment and got it compiling, so just wanted to know if it's still at a known flaky stage, or whether I haven't got my build environment quite right yet.

In reply to by Robbie Matthews

Don't think of this is as just a temporary glitch that will likely be sorted out in a few days, though. The master builds for 3.0 diverged from the 2.x branch quite a while ago and there is very much work here that has never been released and not tested all that much. It's going to be a pretty big release and will likely be a while before it's ready. But it's a great time to have the freedom to try new things!

In reply to by Robbie Matthews

I've been struggling with getting QtCreator to behave.
I can get the command line build to work, but if I attempt to follow instructions and open CMakeLists,txt in qtCreator, it loads (with a bit of fussing) but won't actually compile.
What is more, I have to run a clean and delete CMakeLists.user to get the command build to work again.
I am using CMake 3.9.1... is this a mistake?

Running Windows 10, QT 5.8, MingW 5.3 (32 bit)

NB: I'd show the error, but there are literally thousands of them...

In reply to by Jojo-Schmitz

That helps: I had failed to set CMAKE_BUILD_TYPE, and CMAKE_INSTALL_PREFIX.

QtCreator complained about missing CMAKE_MAKE_PROGRAM, which I set to mingw32-make, and the the configuration seemed to be happy.
However, then I get this error:

'.' is not recognized as an internal or external command,
operable program or batch file.
manual/CMakeFiles/pluginDocumentation.dir/build.make:60: recipe for target 'pluginDocumentation' failed

Investigating the build.make, I find this line
cd C:/Android/MuseScore/build.qtc/manual && ./genManual C:/Android/MuseScore C:/Android/MuseScore/build.qtc/share/manual

Windows does not like running ./genManual from the command line... this is generated code, so I'm not completely sure where I should make changes... or whether I've just put the wrong value in CMAKE_MAKE_PROGRAM.

PS: Paths set as per the current "standard" qt.bat
PPS: In spite of this, I have made some minor but useful changes to my local version around the plugin creator.
PPPS: I know almost nothing about CMake.

In reply to by Jojo-Schmitz

Yeah, I just can't get it to work no matter how carefully I follow the instructions.

The final linking throws 90000+ errors(!)
Along the lines of:
C:\Android\MuseScore\build.qtc\mscore\qrc_musescore.cpp:44062: error: undefined reference to `qRegisterResourceData(int, unsigned char const*, unsigned char const*, unsigned char const*)'

It's not essential to be able to develop in qtCreator, but it would make life easier....
I also need to define QT_WINE_EXECUTABLE and QT_WRC_EXECUTABLE manually, even though they're defined in the toolchain....?
Something is not right...

In reply to by Robbie Matthews

You did set the CMAKE_TOOLCHAIN_FILE, then? And you are building master, using a recent / supported version of Qt for master?

Just to be sure - the "Android" in your pathname doesn't mean you are somehow trying to build for that platform, does it? Looks like it is higher up in the path hierarchy so it's just coincidental?

You shouldn't need to customize those settings. I believe this happens if there is some sort of error in the toolchain. Some stuff gets cached and reused, so your attempts to build before setting thast might be getting in the way. might be best to delete this whole folder and try again, this time being sure to set those variables correctly from the beginning. There are probably individual cache files you could delete instead, but I'm not sure which.

In reply to by Marc Sabatella

Toolschain setting checked and double-checked.

Build is from master.

mingw32-make -f makefile.mingw debug (and release and install) all work OK.

It's when I try to use QtCreator (so I can use the form editor and hopefully the debugger) that it all falls to pieces.
(Actually, I CAN use the form editor, but I've yet to use the debugger)

(And \Android is just the folder I've got most of my open source projects in, I'm not trying to do an Android build...)
See attached screenshots...

Attachment Size
qt1.png 99.51 KB
qt2.png 63.78 KB

In reply to by Jojo-Schmitz

But I do have it set in the Manage Kits screen (see qt2.png in previous comment).

So... that apparently does the trick.
OK, full steps for me to get working, Qt5.8, MIngW 5.3, CMake 3.9:
* I apparently put the CMAKE_TOOLCHAIN_FILE in the wrong damn place, Environment, not CMake Configuration. Sigh.
* If you DO make a mistake, you have to delete build.qtc\CMakeFiles and build.qtc\CMakeCache.txt to make it pick up changes.
* You also need to set CMake Generator to generate MinGW makefiles. This is not the default. (I also set it to Codeblocks, not sure if it is important.
(Bangs head repeatedly on desk)

Thanks for your patience, folks.

In reply to by Robbie Matthews

Glad you got it working! Not sure what you mean about the last comment (setting CMAke Generator to generate MinGW makefiles). The compilation instructions for Linux do include a specific instruction about this that needs to be followed, but I've never needed to do anything special on Windows, and it works for me without having done that - just doing what is in the instructions work every time if I follow them diligently and don't try to improvise (as I've been known to do). Could be still a side effect of a previous run, or maybe different versions of cmake, I guess.

Do you still have an unanswered question? Please log in first to post your question.