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

[Eike Ziller]

> 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