[glib, fltk, cairo, python3] Sequence of adjustments for windows and macos by magicfoo · Pull Request #9593 · microsoft/vcpkg

magicfoo · 2020-01-08T20:39:06Z

This PR provides few minor or more majors adjustments to the following components:

fix glib to support static build on windows
fix cairo to properly build on macos and support quartz rendering
update fltk to support cairo extension
fix python3 to support static build on windows

+ Fix compilation issues with Xcode 11.3 (catalina)

+ Fix build issues on macos

magicfoo · 2020-01-09T00:09:36Z

Interesting to see that the original order of the commits in this stack is displayed differently here. I don't guarantee a random order will build properly. Preferably, glib < cairo < fltk < fluid < python < yaml.
Note: Patch on fluid could be a better PR on the fltk repo itself than a patch here ...

PhoebeHui · 2020-01-09T07:32:04Z

/azp run

PhoebeHui · 2020-01-09T07:39:09Z

ports/python3/portfile.cmake

Could you please merge the code in two 'if (VCPKG_LIBRARY_LINKAGE STREQUAL static)' ?

if (VCPKG_LIBRARY_LINKAGE STREQUAL static) vcpkg_apply_patches( SOURCE_PATH ${SOURCE_PATH} PATCHES 0001-Static-library.patch 0003-Fix-header-for-static-linkage.patch 0004-Remove-linktime-global-optimization.patch ) endif()

Same as above, function is deprecated, please use a symbol which resolves to an empty string when not necessary

0002 collides with 0001 and 0004, so it can't be re-ordered. That said, it is not easy to dissociate the CRT and LIB mode patches. Also, keeping this granularity could be great. But we don't want 4^2 patch files for all combinations of CRT (static or not) and LIB (static or not). Any suggestion? Easy way could be to consider a unique static or not cfg build vs dynamic.

PhoebeHui · 2020-01-09T07:56:20Z

@magicfoo, thanks for the PR!

The following port failed on CI, could you take a look? for glib:x64-windows-static, it passed on CI testing, could you remove it from from ci.baseline, if some of the failures are expected, please also add it to ci.baseline file.

Failed on x86-windows/x64-windows:
REGRESSION: gmime:x86-windows
REGRESSION: harfbuzz:x86-windows
REGRESSION: glibmm:x86-windows

Failed on x64-windows-static:
REGRESSION: glibmm:x64-windows-static
REGRESSION: lcm:x64-windows-static
REGRESSION: fluidsynth:x64-windows-static
REGRESSION: pango:x64-windows-static
REGRESSION: openscap:x64-windows-static
REGRESSION: atk:x64-windows-static
REGRESSION: gdk-pixbuf:x64-windows-static
PASSING, REMOVE FROM FAIL LIST: glib:x64-windows-static (C:\vsts_work\3\s\scripts\ci.baseline.txt)
REGRESSION: gts:x64-windows-static

cenit · 2020-01-09T11:10:04Z

ports/fltk/find-lib-png.patch

modifications from here going on are whitespace-only, am I right?
if so, can you please remove them in order to simplify patchset?

cenit · 2020-01-09T11:16:20Z

ports/libyaml/portfile.cmake

vcpkg_apply_patches is deprecated. Can you please define something like

if (VCPKG_TARGET_IS_WINDOWS) set(WIN_PATCH "fix-POSIX_name.patch") endif()

and then use ${WIN_PATCH} directly above? in this way it is applied only on windows without using a deprecated function (which might trigger a fatal error if the user does not delete buildtrees folder every time!)

This is more tricky AFAIK. The CRT linkage is not part of the triplet and the original source code is shared by vcpkg between the dynamic and static versions of those 2 builds. To prevent this, this port file duplicates the source code locally into 2 working folders named according to VCPKG_CRT_LINKAGE. Then different patches could be applied to those distinct source dirs, especially the patch 0002 building the lib with static CRT.

The very first lines exclude the configuration (lib=dynamic,crt=static) for good reasons. But the config (lib=static,crt=dynamic) is acceptable, but not managed by vcpkg at this level of granularity. I hope I was clear in my explanations here. A consequence of this is the patches can't be applied to the original source code ('from_github') and must be processed later ... I personally agree this is ugly but I don't see atm better option. The best thing to do IMHO is to manage the CRT linkage as the same level the LIB linkage is exposed by VCPKG to the user, extending the triplet x64-windows-static to a quadruplet x64-windows-static-static?? Not ideal, but at least, this is robust.

Sorry I lost you. Will need to inspect the port better to understand the problem you are trying to explain

Let me try a shorter version: The original source code can't be patched directly (using PATCHES arg in the vcpkg_from_github function call) as the patches to apply depend on the CRT and LIB linkage modes. This port duplicates the source code to distinctly apply the proper patches on dedicated copies.

Options could be:

have vcpkg to generate multiple variants of the source code according to triplet + CRT linkage that could be patched one, and reused later in other builds

reverse the patches into a single instance of the source code before to patch again in order to patch dynamically based on the current triplet+CRT

Ideally, we would like vcpkg to do the minimal of work each time we run/resume a build, without to redo everything, be reliable and efficient like some build systems do (tuple, scons, etc).

we would like vcpkg to do the minimal of work each time we run/resume a build, without to redo everything

that's not how vcpkg works. It deletes everything and restarts from scratch, apart from keeping the uncompressed sources files + patches eventually applied

The triplet is unique, in that a single triplet defines CRT linkage and LIB linkage. So ideally you can apply the idea of having symbols that resolves to nothing depending on the proper configuration at build time

also, remember that vcpkg_apply_patches is really broken if used directly in portfiles. It's NOT robust, not at all! It fails always the second time you run an install with the same parameters without manually deleting buildtrees folder

apart from keeping the uncompressed sources files + patches eventually applied

This is exactly the reason why we can't apply those patches on the source files provided by vcpkg but have to duplicate the code per LIB+CRT config.

I rewrote a proposal for the python3 port file which look clean to me. Few things I don't like like the vcpkg_build_msbuild that build for debug and release by itself. At least we should have an option to decide about this behavior. I got around by wrapping the function call forcing one build type at the time.

This is exactly the reason why we can't apply those patches on the source files provided by vcpkg but have to duplicate the code per LIB+CRT config.

vcpkg calculate a hash for the source files + applied patches. So if the patchset is ok, it recycles the buildtrees source folder, otherwise if the patchset for the new build (different crt linkage, different lib linkage, different os, whatever that makes any symbol be empty for example) is different, the hash will not match and another source tree will be expanded and the appropriate patch files applied.

If you use modern vcpkg routines, you will find that what you are trying to do manually with code duplication and patch manually applied would be handled automatically

magicfoo · 2020-01-09T20:48:22Z

@magicfoo, thanks for the PR!

The following port failed on CI, could you take a look? for glib:x64-windows-static, it passed on CI testing, could you remove it from from ci.baseline, if some of the failures are expected, please also add it to ci.baseline file.

Failed on x86-windows/x64-windows:
REGRESSION: gmime:x86-windows
REGRESSION: harfbuzz:x86-windows
REGRESSION: glibmm:x86-windows

Failed on x64-windows-static:
REGRESSION: glibmm:x64-windows-static
REGRESSION: lcm:x64-windows-static
REGRESSION: fluidsynth:x64-windows-static
REGRESSION: pango:x64-windows-static
REGRESSION: openscap:x64-windows-static
REGRESSION: atk:x64-windows-static
REGRESSION: gdk-pixbuf:x64-windows-static
PASSING, REMOVE FROM FAIL LIST: glib:x64-windows-static (C:\vsts_work\3\s\scripts\ci.baseline.txt)
REGRESSION: gts:x64-windows-static

The failing build in x64-windows-static are not really regression, as they never work pass before this commit fixing glib in static build. I checked few of them and they fail on a missing intl static lib. They could be fixed later but IMHO should not block this PR.

… non-window parent

JackBoosY · 2020-01-10T08:39:21Z

ports/fltk/find-lib-cairo.patch

Can you delete these three lines instead of commenting them out?

Thanks.

JackBoosY · 2020-01-10T08:39:57Z

ports/fltk/find-lib-png.patch

Can you delete these three lines instead of commenting them out?

Thanks.

JackBoosY · 2020-01-10T08:40:12Z

ports/fltk/find-lib-png.patch

JackBoosY · 2020-01-10T08:40:16Z

ports/fltk/find-lib-png.patch

JackBoosY · 2020-01-10T08:42:24Z

ports/fltk/portfile.cmake

This directory should be deleted by vcpkg_fixup_cmake_targets, what files does it contain?

JackBoosY · 2020-01-10T08:48:05Z

ports/libyaml/portfile.cmake

Can you remove this line? We don't need to include it now.

JackBoosY · 2020-01-10T08:50:25Z

ports/python3/portfile.cmake

We can use conditions to determine whether changes in these patches will be executed, so that these patches can always be applied.

JackBoosY · 2020-01-10T08:50:44Z

ports/python3/portfile.cmake

JackBoosY · 2020-01-10T08:50:55Z

ports/python3/portfile.cmake

JackBoosY · 2020-01-10T08:53:12Z

ports/python3/portfile.cmake

Can you change these code to vcpkg_configure_make[1] / vcpkg_install_make[2] ?

[1]. https://github.com/microsoft/vcpkg/blob/master/docs/maintainers/vcpkg_configure_make.md
[2]. https://github.com/microsoft/vcpkg/blob/master/docs/maintainers/vcpkg_install_make.md

+ Remove Py_DEBUG in debug build config altering PyModule_Create() symbol + Remove conflicting link time (LT) optimizations in Windows profile

LilyWangL · 2020-04-14T08:46:54Z

Pinging @magicfoo for response. Is work still being done for this PR?

JackBoosY · 2020-05-14T02:45:17Z

Closing this PR since it seems that no progress is being made. Please reopen if work is still being done.

magicfoo changed the title ~~Sequence of commits adjusting fltk + cairo + python3 on windows and macos~~ [fltk, cairo, python3] Sequence of adjustments for windows and macos Jan 8, 2020

magicfoo changed the title ~~[fltk, cairo, python3] Sequence of adjustments for windows and macos~~ [glib, fltk, cairo, python3] Sequence of adjustments for windows and macos Jan 8, 2020

magicfoo force-pushed the comp branch 2 times, most recently from 8706849 to a36a356 Compare January 8, 2020 22:43

magicfoo added 2 commits January 8, 2020 17:45

[glib] Add static build support on windows

8af9571

+ Fix compilation issues with Xcode 11.3 (catalina)

[cairo] Add Quartz support on macos platform

49731f8

+ Fix build issues on macos

magicfoo force-pushed the comp branch from f42300c to f04f905 Compare January 8, 2020 23:46

JackBoosY requested a review from PhoebeHui January 9, 2020 02:51

JackBoosY assigned PhoebeHui and JackBoosY Jan 9, 2020

JackBoosY self-requested a review January 9, 2020 02:51

PhoebeHui reviewed Jan 9, 2020

View reviewed changes

cenit reviewed Jan 9, 2020

View reviewed changes

magicfoo added 2 commits January 9, 2020 16:14

[fltk] Update to FLTK 1.4 + add cairo extension

c1b9a58

[fluid/fltk] Patch FLUID tool allowing relative positioning on top of…

e16e9fc

… non-window parent

magicfoo force-pushed the comp branch from f04f905 to e1ff6c0 Compare January 9, 2020 22:48

JackBoosY suggested changes Jan 10, 2020

View reviewed changes

magicfoo mentioned this pull request Jan 10, 2020

[moltenvk] add new port #9575

Closed

[libyaml] Preserve strdup() on Mac OSX

04fe29b

magicfoo force-pushed the comp branch from e1ff6c0 to d3d6846 Compare January 10, 2020 21:59

[python3] Restore support of windows static build

b7f17b8

+ Remove Py_DEBUG in debug build config altering PyModule_Create() symbol + Remove conflicting link time (LT) optimizations in Windows profile

magicfoo force-pushed the comp branch from d3d6846 to b7f17b8 Compare January 10, 2020 22:12

SeekingMeaning mentioned this pull request Jan 13, 2020

Update baseline to fix osx failure #9600

Merged

15 tasks

JackBoosY added the waiting for response label Jan 19, 2020

LilyWangL mentioned this pull request Apr 7, 2020

glib build failure #10701

Closed

JackBoosY closed this May 14, 2020

Conversation

magicfoo commented Jan 8, 2020

Uh oh!

magicfoo commented Jan 9, 2020

Uh oh!

PhoebeHui commented Jan 9, 2020

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

PhoebeHui commented Jan 9, 2020

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

magicfoo Jan 10, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cenit Jan 10, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

magicfoo commented Jan 9, 2020

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

LilyWangL commented Apr 14, 2020

Uh oh!

JackBoosY commented May 14, 2020

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

magicfoo Jan 10, 2020 •

edited

Loading

cenit Jan 10, 2020 •

edited

Loading