Re: [Mingw-cross-env-list] Qt5 Shared / Travis-CI

[Jonathan Greig]

Mark,

Just got done building, and I did encounter the same issue again:

Qt5 GUI app (embroidermodder2.exe) written in C++ and should work with mxe's qmake: FAIL

Command line converter app (libembroidery-convert.exe) which is written in C89 and does not rely on Qt, but I use mxe's qmake to build it: PASS

Here is exactly how I cross-compiled the executables:

cd embroidermodder2
make distclean
export PATH=/mydata/mxe/usr/bin:$PATH
/mydata/mxe/usr/i686-pc-mingw32.static/qt5/bin/qmake CONFIG+=deploy
make
[embroidermodder2.exe is successfully made but fails in windows]
cd ../libembroidery-convert
make distclean
/mydata/mxe/usr/i686-pc-mingw32.static/qt5/bin/qmake CONFIG+=deploy
make
[libembroidery-convert.exe is successfully made and actually runs on windows]

Am I missing a step or is this really a problem?

I've attached pictures showing the result in my VM.

I'm not sure why you would need both JOBS=4 and -j4 but if it does help, I'll try that next time around. 45 minutes isn't too bad. I've had Qt5 builds take 2-3 hours on other machines. Either way, as Tim showed above, 45 minute builds are not allowed in Travis-CI. I don't care as much how long it takes in Travis-CI to build but the quicker the better. And using Travis-CI is extremely important because it is how we have our nightly/continuous builds setup. I get requests for builds quite a bit, by developers and non-developers alike. Whenever someone asks for a build, I just point them to the nightly link. Easy. Done. If our build passes, the nightly repo is updated. If it fails, the last working build is always available. Our nightly repo already has linux64 builds and works great. I have tested OSX homebrew builds thru Travis-CI and that will be incorporated soon. Arduino integration testing for our code will be added using ino-tool. Native windows builds thru Travis-CI are not possible yet, but that doesn't mean that I shouldn't test cross-compiling for Windows since I've never had any issues in the past with Qt4 using the unsupported/win32-g++-cross mkspec.

Jonathan

On Fri, Mar 7, 2014 at 4:21 AM, Mark Brand <address@hidden> wrote:

The most recent problem I had in the past was that MXE created the executable just fine, yet it was corrupt and would not run. I even had two independent parties test the executable outside of a VM and they confirmed it didn't work either. That was on January 26, 2014 so that is probably the same day when I cloned it.

I've never encountered this problem personally. If you run into it again, please bring it up here or open an issue in github.

A large majority of the other issues were the constant problem that one package would fail to build for one reason or another or even fail because the download link may have been down or a bug in the particular submodule unrelated to MXE. There really needs to be some sort of a backup procedure that MXE does that happens when this occurs that ensures just because the main link is down, it should use a mirror or other method(like pulling a known previously built binary or source package right from an MXE github repo similar to what I mentioned above concerning the Travis-CI issue Tim explained above).

MXE has a backup package cache now, so this problem should be solved.

I cloned the latest master earlier tonight and will be trying it statically later(Like Tim mentioned, it does exceed 45 minutes, so you must really enjoy your coffee hehe). Here is the output which looks normal so far:

    address@hidden:/mydata/mxe$ git clone -b master
    https://github.com/mxe/mxe.git

    address@hidden:/mydata/mxe$ make -j4 qt5

It might speed things up a bit if you add JOBS=4  as well as -j4. 45 minutes isn't that bad though, is it?


Mark

fail.png
Description: PNG image

pass.png
Description: PNG image