All right, many thanks for the feedback. Marco Il 31 ago 2016 3:06 PM, "Eike Ziller" <[email protected]> ha scritto:
> > > On Aug 31, 2016, at 2:33 PM, Marco Piccolino < > [email protected]> 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 <[email protected]>: > > > > > On Aug 31, 2016, at 11:22 AM, Marco Piccolino < > [email protected]> 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 > > > [email protected] > > > http://lists.qt-project.org/mailman/listinfo/qt-creator > > > > -- > > Eike Ziller > > Principal Software Engineer > > > > The Qt Company GmbH > > Rudower Chaussee 13 > > D-12489 Berlin > > [email protected] > > 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 > [email protected] > http://qt.io > Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja > Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht > Charlottenburg, HRB 144331 B > > > > >
_______________________________________________ Qt-creator mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/qt-creator
