Bug 382421 - Native windows build system required
Summary: Native windows build system required
Status: RESOLVED WORKSFORME
Alias: None
Product: umbrello
Classification: Applications
Component: general (show other bugs)
Version: frameworks5
Platform: Other Microsoft Windows
: NOR normal
Target Milestone: ---
Assignee: Umbrello Development Group
URL:
Keywords: triaged
Depends on:
Blocks: 373980
  Show dependency treegraph
 
Reported: 2017-07-17 07:18 UTC by Ralf Habacker
Modified: 2018-10-28 03:31 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ralf Habacker 2017-07-17 07:18:52 UTC
To be able to compile umbrello native on Windows it is required to have a native Windows build system.

System requirements:
1. Laptop or desktop pc with i5 or i7 (4-12 cores) the more the better
2. 512 GB SSD
3. >= 8GB RAM 

software:
1. MS Visual Studio Express 2015
2. craft
3. git
Comment 1 Luigi Toscano 2017-09-29 21:43:01 UTC
Please note that this is not really a bug of the product; this is more a task that can be captured on Phabricator. Moreover KDE infrastructure provide build.kde.org and a (work in progress, but working) server for building binary artifacts (installer included).
Comment 2 Ralf Habacker 2017-09-29 22:21:19 UTC
(In reply to Luigi Toscano from comment #1)
> Please note that this is not really a bug of the product; this is more a
> task that can be captured on Phabricator.
With the drawback that you cannot have a complete overview in term of kind of project management because bugs and features are also a kind of task. I read somewhere that bugs/features will stay in bugs.kde.org and unfortunally phabricator tasks could not link or depends on bugs.kde.org tickets.

> Moreover KDE infrastructure
> provide build.kde.org
which is a remote only build system and makes it hard or nearly impossible to fix hidden build issues where jenkins does not provide enough informations to see the root cause of the issue. Because of this I switched to SUSE obs for building KDE Windows packages, which provides a local build client named osc.

>  and a (work in progress, but working) server for building binary artifacts (installer included).
Does it provide a local build client and support for building autotools based packages, which are required for example for building kmymoney ?
Comment 3 Luigi Toscano 2017-09-29 22:33:51 UTC
(In reply to Ralf Habacker from comment #2)
> (In reply to Luigi Toscano from comment #1)
> > Please note that this is not really a bug of the product; this is more a
> > task that can be captured on Phabricator.
> With the drawback that you cannot have a complete overview in term of kind
> of project management because bugs and features are also a kind of task. I
> read somewhere that bugs/features will stay in bugs.kde.org and unfortunally
> phabricator tasks could not link or depends on bugs.kde.org tickets.

IMHO I think that the project tracking can be done on phabricator even now (not different than what people using Trello for example do). Yes, bugs are going to be "normal" links for now, but still. Of course feel free to raise this need to the sysadmin team (in the Phabricator workboard).

> 
> > Moreover KDE infrastructure
> > provide build.kde.org
> which is a remote only build system and makes it hard or nearly impossible
> to fix hidden build issues where jenkins does not provide enough
> informations to see the root cause of the issue. Because of this I switched
> to SUSE obs for building KDE Windows packages, which provides a local build
> client named osc.

Does OBS build remotely, so you get the logs from osc? In this case, which additional logs are available there which are missing from build.kde.org? If our sysadmin knew about them, they could collect more data.

> 
> >  and a (work in progress, but working) server for building binary artifacts (installer included).
> Does it provide a local build client and support for building autotools
> based packages, which are required for example for building kmymoney ?

I guess that autotools are required for KMyMoney dependencies (which is out of scope for this bug). It's based on craft, so I guess that the answer is yes (craft being the tool to build locally, and support for autotools-based builds: https://cgit.kde.org/craft-blueprints-kde.git/tree/autotools ).
Comment 4 Luigi Toscano 2017-10-01 13:02:22 UTC
Compilation successful on the CI:
https://build.kde.org/job/Applications%20umbrello%20kf5-qt5%20WindowsMSVCQt5.9/5/
Comment 5 Ralf Habacker 2017-10-01 14:52:03 UTC
(In reply to Luigi Toscano from comment #3)
> > > Moreover KDE infrastructure
> > > provide build.kde.org
> > which is a remote only build system and makes it hard or nearly impossible
> > to fix hidden build issues where jenkins does not provide enough
> > informations to see the root cause of the issue. Because of this I switched
> > to SUSE obs for building KDE Windows packages, which provides a local build
> > client named osc.
> 
> Does OBS build remotely, so you get the logs from osc? In this case, which
> additional logs are available there which are missing from build.kde.org? If
> our sysadmin knew about them, they could collect more data.

For example in case of cmake configure errors on obs I add --trace to the spec file through the web frontend at https://build.opensuse.org/package/show/home:rhabacker:branches:windows:mingw:win64/mingw64-kmymoney and let it rebuild, then I get detailed configure logs. Or if there are hidden build issues (missing dependencies of not included object files or not generating required files I add VERBOSE=1 (for cmake level) and/or V=1 (for make level) to the spec file and get it on the next build. 

Is this possible with build.kde.org ? 

There are cases where all that does not help to find the hidden issue, for example compile errors.
I can locally check out the related obs project on a linux system and rebuild it locally, can inspect all generated files by using the obs command line client osc. I proofed that this has been required several times. Does jenkins provide this also with a negligible effort ?
   
> > >  and a (work in progress, but working) server for building binary artifacts (installer included).

do not work for umbrello, see https://binary-factory.kde.org/job/umbrello-stable-win32/34/console.

If that will be fixed, there is still the issue how to deal with for example compile errors which sometimes are *very* hard to find. How can you find the root bug cause without having access to *all* build related files because you do not know in which file the root causse may be. With craft you need a native windows build system to rebuild all dependencies locally to get this. This is a very time and hd space consuming job. 

I do not have a big local windows build machine (requires at least quad core and several 100 GB hd space) for performing the builds which is required to build msvc builds using the KDE infrastructure and there are no accessable windows build machines for KDE users so it looks to be impossible to go that road.

With obs you can rebuild a package locally simply by checking out the related project from obs and running  "osc build <repository>" which fetches binary packages for all related dependencies out of the box and build the package (which requires about 1.5 G hd space)

Would that possible ?
Comment 6 Andrew Crouthamel 2018-09-28 02:31:01 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information.

For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 7 Andrew Crouthamel 2018-10-28 03:31:03 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information.

For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!