Not 100% sure, but assuming the macx-clang mkspec actually exists, I think that your Qt installation is not relocatable. Although locally I tried moving the online installed qt dir, and invoking qmake on an example worked fine.
Maybe try running qmake -d .. &> log.txt and check if that gives you any info on which paths qmake is looking for. Maybe setting a qt.conf with a PrefixPath might also help. Just some suggestions. On Mon, Feb 18, 2019 at 1:08 PM Nuno Santos <nunosan...@imaginando.pt> wrote: > Hi, > > I have found this slide deck very very very interesting. > > http://www.slidedeck.io/lasconic/qtci-qtcon2016 > > > It seems that MuseScore doing precisely what I want to do with Travis help. > > I became aware that Travis can build for Mac OSX. I didn’t knew that. And > that it is possible to build for windows as well through AppVeyor. This > were my number one requirements for this CI quest so I decided to give it a > try. > > I don’t have time to go through all the configuration steps from the > scratch with Jenkins. Yes, I could save money because Jenkins is free, but > time is money too and time is my most valuable resource. > > > I’m now tinkering around a Mac OSX build with Travis but I’m running into > a problem… > > For my desktop builds I depend on a static build of Qt. Obviously I don’t > want to compile Qt from source at each build so I’m downloading into the > worker a prebuilt Qt kit and I’m calling my build script which will call > qmake on the project, on the worker environment. The problem is: > > 1.06s$ ./build.sh > Building app.pro on 1550491076 > *Could not find qmake spec 'macx-clang'.* > > qmake is returning with the error above, saying that it can’t find qmake > spec ‘macx-clang’ > > What are the possible reasons for qmake to return with such error? What is > qmake looking for that it can’t find? > > Does anyone has an idea why this is happening? > > Thanks in advance! > > Regards, > > Nuno > > On 17 Feb 2019, at 15:33, Croitor Alexandru <placi...@gmail.com> wrote: > > Hi, > > The mentioned qtci repo https://github.com/benlau/qtci also has two > reference links which look useful. Pasting here as well. > > http://www.slidedeck.io/lasconic/qtci-qtcon2016 > > http://andrewdolby.com/articles/2016/continuous-deployment-for-qt-applications/ > > Another source of inspiration can be the travis and appveyor config files > at https://github.com/bjorn/tiled which is a Qt application built with > qbs. > > One provider also worth considering is VSTS / Azure Pipelines. > > They offer free CI / CD and free runners (Windows, Linux, macOS) for open > source Git projects. > https://azure.microsoft.com/en-us/services/devops/pipelines/ > They claim each job can be up to 6 hours, which is higher than what Travis > allows iirc. > > Some discussion about it can be found here > https://www.reddit.com/r/programming/comments/9enz31/announcing_azure_pipelines_with_unlimited_cicd/ > > Cheers. > > On Sun, Feb 17, 2019 at 3:34 PM René Hansen <ren...@gmail.com> wrote: > >> Does anyone have any experience using Travis for for Qt projects? >> >> I found this project, which seems to at least have a good general >> approach to setting up a usable environment for Travis: >> >> https://github.com/benlau/qtci >> >> If anyone has tried using it, I'd love to hear about it. >> >> >> /René >> >> On Thu, 14 Feb 2019 at 10:22 Elvis Stansvik <elvst...@gmail.com> wrote: >> >>> Den tors 14 feb. 2019 kl 10:08 skrev Nuno Santos < >>> nunosan...@imaginando.pt>: >>> > >>> > Hey, >>> > >>> > Thank you all for sharing your solutions and approaches. Among here >>> there are two obvious winners: >>> > >>> > - Jenkins >>> > - Buildbot >>> > >>> > I want to keep the build config within the project so I guess Jenkins >>> will be my way to go. >>> >>> For brevity, this is the side-project I mentioned to make Buildbot >>> more like Travis in that respect: >>> https://github.com/buildbot/buildbot_travis >>> >>> It's maintained (and I believe used) by the Buildbot maintainers >>> themselves. I've looked at it, but we haven't tried to use it. One >>> reason is that it works by dynamically adjusting the Buildbot config, >>> and I was unsure how this would work if we still wanted to have parts >>> of the Buildbot config that were custom/static (like I mentioned, we >>> have some other automation tasks that we run on top of the same >>> Buildbot master instance). >>> >>> Anyway, just thought I'd drop the link. Probably good idea to go with >>> Jenkins if you want in-repo build recipies out of the box. >>> >>> Elvis >>> >>> > >>> > Now I just need to go though all the configuration details. If anyone >>> knows any really pragmatic documentation on how to setup Jenkins server >>> with GitHub and how to setup a worker on Mac and Windows, please share. >>> > >>> > Thanks, >>> > >>> > Best regards, >>> > >>> > Nuno >>> > >>> > On 13 Feb 2019, at 19:02, Elvis Stansvik <elvst...@gmail.com> wrote: >>> > >>> > Den ons 13 feb. 2019 kl 00:06 skrev Nuno Santos < >>> nunosan...@imaginando.pt>: >>> > >>> > >>> > Hi, >>> > >>> > I’m curious about what you Qt heads are using for continuous >>> integration. >>> > >>> > I have googled a few times this for this topic and I have found a >>> couple of options but every time I tried to spend the minimum amount of >>> time to setup one, it seems an incredible effort. I’m looking for a >>> solution that allows me to: >>> > >>> > - push to a specific branch on GitHub >>> > - get a local CI agent to fetch that branch and build it >>> > >>> > Ideally I would like it to be : >>> > >>> > - fast to setup >>> > - Windows & Mac compatible >>> > - ideally with docker integration >>> > >>> > Drone works damn well for web projects. I wanted something that cool >>> for automatic desktop software building and packaging >>> > >>> > What are you people using? >>> > >>> > >>> > We use Buildbot. It has worked very well, and we use it for some other >>> > automation tasks besides software builds. It builds and tests software >>> > from our local GitLab instance. Builds are mostly done in Docker >>> > containers, though for macOS and Windows we run the Buildbot workers >>> > on bare metal. >>> > >>> > Downside is it's configured using Python and the configuration takes >>> > some getting used to when setting it up for the first time (but it's >>> > very well designed and worth learning). The upside is it's Python :) >>> > so it's *very* flexible. Downside is also that the config is central >>> > and not kept with the repos (though there is a project to support >>> > Travis-style in-repo config). >>> > >>> > Elvis >>> > >>> > >>> > Thanks! >>> > >>> > Best, >>> > >>> > Nuno >>> > _______________________________________________ >>> > Interest mailing list >>> > Interest@qt-project.org >>> > https://lists.qt-project.org/listinfo/interest >>> > >>> > >>> > _______________________________________________ >>> > Interest mailing list >>> > Interest@qt-project.org >>> > https://lists.qt-project.org/listinfo/interest >>> _______________________________________________ >>> Interest mailing list >>> Interest@qt-project.org >>> https://lists.qt-project.org/listinfo/interest >>> >> _______________________________________________ >> Interest mailing list >> Interest@qt-project.org >> https://lists.qt-project.org/listinfo/interest >> > _______________________________________________ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest > > > _______________________________________________ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest >
_______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
