[Qt-creator] Best workflow to manage pre-configured version

[Marco Piccolino]

All right,
many thanks for the feedback.
Marco

Il 31 ago 2016 3:06 PM, "Eike Ziller" <Eike.Ziller at qt.io> ha scritto:

>
> > On Aug 31, 2016, at 2:33 PM, Marco Piccolino <
> marco.a.piccolino at gmail.com> wrote:
> >
> > Thanks Eike!
> >
> > Supported platforms are Windows, OSX and Linux, with Windows being the
> priority ATM.
> > So you say the second workflow is also potentially viable without
> getting mad as long as the platforms to be maintained are just a few?
>
> No, I wanted to say that WORKFLOW 1 becomes a lot more work the more
> platforms you want to support.
>
> As long as you really only need a different share/ folder, WORKFLOW 2
> could be done on a single machine for all three platforms, basically just
> unzipping the binaries, replacing (parts of) the share/ folder, zip up
> again (except that you probably will want an installer for Windows in the
> end, because you need to make sure that the correct C++ runtime environment
> is installed.
>
> WORKFLOW 1 involves setting up complete build environments on all three
> platforms, which need to be upgraded when Qt Creator build requirements
> change (e.g. master/4.2 now requires MSVC2015 on Windows), making sure that
> on Linux you do not link against too new standard libs (because then the
> result will not run on older Linuxes), etc, etc.
>
> Replacing the share/ folder you need to do in both cases, though you might
> get some help from git in WORKFLOW 1 (though maybe not).
>
> You can also go a hybrid way: Set up your own fork/branch like in WORKFLOW
> 1 for local testing when you update the Qt Creator version, but for actual
> distribution go the way of WORKFLOW 2 with the fixed result of your share/
> folder from local testing.
>
> Br, Eike
>
> > Marco
> >
> > 2016-08-31 14:24 GMT+02:00 Eike Ziller <Eike.Ziller at qt.io>:
> >
> > > On Aug 31, 2016, at 11:22 AM, Marco Piccolino <
> marco.a.piccolino at gmail.com> wrote:
> > >
> > > Hello!
> > >
> > > Given that:
> > >
> > > - We need to ship a pre-configured version of QC to support our SDK.
> > > - We only need a subset of what QC provides out of the box, and the
> customization we want seems to be achievable by just changing the "share"
> configuration (ini, xml etc.)
> > > - We don't need to always provide the latest version of Creator
> > > - The SDK does not need Qt right now, but it will in the near future
> > > - Currently supported projects will be written in C and for this
> reason we will most likely want to only support Cmake, at least for the
> time being
> > >
> > > Given this premise, what is the best workflow to maintain such a
> custom version of Creator?
> > >
> > > Here are two options I came up with and would like to have any
> feedback on their maintainability and better alternatives, especially in
> the light that now pre-compiled Creator is shipped with an installer,
> >
> > Independent from the installers, the files that are installed by the
> installers are found e.g. here:
> > http://download.qt.io/official_releases/qtcreator/4.
> 1/4.1.0/installer_source/
> > The 7zips there can be unpacked and run anywhere, of course minus any
> special things the installers do, like ensuring that the correct MSVC
> runtime is installed on Windows, and registering start menu / desktop
> entries on Windows and Linux.
> >
> > >  as per recent discussion here:
> > >
> > > WORKFLOW 1
> > >
> > > 1 - fork/clone QC's repo to my-qc repo
> > > 2 - define QC version we want to use (good candidate seems upcoming
> 4.1 because of improved CMake support)
> > > 3 - create new branch (my-qc_4.1) in myQC repo from selected branch
> (4.1)
> > > 4 - create a set of scripts in separate repo (my-qc-scripts) that
> makes all modifications we want to "shared" folder in my-qc_4.1
> > > 5 - run my-qc-scripts on my-qc_4.1
> > > 6 - build from my-qc 4.1
> > > 7 - distribute the custom builds (without installer?)
> >
> > The amount of work that this is compared to the second option depends
> much on which (/how many) client platforms you want to support, I’d say.
> >
> > > An alternative to this for me would be to:
> > >
> > > WORKFLOW 2
> > >
> > > 1 - take QC pre-built packages for the platforms we want to support
> > > 2 - create a repo in their respective "share" folders
> > > 3 - create my-qc-scripts that modify the "share" folders (possibly
> platform-specific)
> > > 4 - run my-qc-scripts on the "share" folders of the prebuilt versions
> > > 5 - distribute the pre-built versions with custom "share" folder
> > >
> > > The second options avoids having to compile custom builds but seems a
> bit dirtier and less maintainable, especially in the long run.
> > >
> > > Any input is highly appreciated.
> > >
> > > Many thanks,
> > > Marco Piccolino
> > >
> > >
> > >
> > > _______________________________________________
> > > Qt-creator mailing list
> > > Qt-creator at qt-project.org
> > > http://lists.qt-project.org/mailman/listinfo/qt-creator
> >
> > --
> > Eike Ziller
> > Principal Software Engineer
> >
> > The Qt Company GmbH
> > Rudower Chaussee 13
> > D-12489 Berlin
> > eike.ziller at qt.io
> > http://qt.io
> > Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
> > Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht
> Charlottenburg, HRB 144331 B
> >
> >
> >
> >
> >
>
> --
> Eike Ziller
> Principal Software Engineer
>
> The Qt Company GmbH
> Rudower Chaussee 13
> D-12489 Berlin
> eike.ziller at qt.io
> http://qt.io
> Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
> Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht
> Charlottenburg, HRB 144331 B
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/qt-creator/attachments/20160831/4a018da5/attachment.html>