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

[Marco Piccolino]

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?

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
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/qt-creator/attachments/20160831/899b12b2/attachment.html>