[Interest] What are you using for continuous integration?

Mon Feb 18 13:22:36 CET 2019

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 <nunosantos at 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 <placinta at 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 <renehh at 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 <elvstone at gmail.com> wrote:
>>
>>> Den tors 14 feb. 2019 kl 10:08 skrev Nuno Santos <
>>> nunosantos at 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 <elvstone at gmail.com> wrote:
>>> >
>>> > Den ons 13 feb. 2019 kl 00:06 skrev Nuno Santos <
>>> nunosantos at 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 at qt-project.org
>>> > https://lists.qt-project.org/listinfo/interest
>>> >
>>> >
>>> > _______________________________________________
>>> > Interest mailing list
>>> > Interest at qt-project.org
>>> > https://lists.qt-project.org/listinfo/interest
>>> _______________________________________________
>>> Interest mailing list
>>> Interest at qt-project.org
>>> https://lists.qt-project.org/listinfo/interest
>>>
>> _______________________________________________
>> Interest mailing list
>> Interest at qt-project.org
>> https://lists.qt-project.org/listinfo/interest
>>
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> https://lists.qt-project.org/listinfo/interest
>
>
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> https://lists.qt-project.org/listinfo/interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20190218/2b3b5241/attachment.html>