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

[Eike Ziller]

> 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