Page MenuHomeFreeBSD

devel/glib20: Update to 2.66.7
ClosedPublic

Authored by otis on Feb 13 2021, 11:57 AM.
Tags
None
Referenced Files
Unknown Object (File)
Mon, Nov 25, 7:02 AM
Unknown Object (File)
Mon, Nov 25, 7:02 AM
Unknown Object (File)
Mon, Nov 25, 7:02 AM
Unknown Object (File)
Mon, Nov 25, 6:59 AM
Unknown Object (File)
Mon, Nov 25, 6:59 AM
Unknown Object (File)
Mon, Nov 25, 6:59 AM
Unknown Object (File)
Mon, Nov 25, 6:59 AM
Unknown Object (File)
Mon, Nov 25, 6:59 AM

Details

Summary
  • Update to 2.66.7
  • Reformat Makefile a bit according to portclippy/portfmt

Changelog: https://fossies.org/linux/glib/NEWS

Diff Detail

Repository
rP FreeBSD ports repository
Lint
No Lint Coverage
Unit
No Test Coverage
Build Status
Buildable 36963
Build 33852: arc lint + arc unit

Event Timeline

otis requested review of this revision.Feb 13 2021, 11:57 AM

Do not silence commands in Makefile.

Fix some nits:

  • use python 3.6+
  • USES should be "=", not "+="
diizzy added inline comments.
devel/glib20/Makefile
4–5

Use DISTVERSION
See Porter's Handbook - "Table 5.2. Package Naming Examples"

16

"Initial" variables should use = not +=

21

Same as previous comment

22

3.6 is the oldest supported version of the Python 3.X branch
https://svnweb.freebsd.org/ports/head/Mk/Uses/python.mk?revision=564032&view=markup#l22

56

Why is this defined separately?

70

What's the reasoning behind stripping @ ?

otis added inline comments.
devel/glib20/Makefile
4–5

Use DISTVERSION
See Porter's Handbook - "Table 5.2. Package Naming Examples"

I am indifferent on this. @tcberner your thought?

70

What's the reasoning behind stripping @ ?

Commands should not be silenced.

devel/glib20/Makefile
4–5

I think DISTVERSION is fine here.

tcberner added inline comments.
devel/glib20/Makefile
42

^ you could move these three after the options block, see https://docs.freebsd.org/en_US.ISO8859-1/books/porters-handbook/porting-order.html 15.11

While you're here, the names makes those sound like flavor settings (due to the lovercase_UPPERCASE pattern). -- maybe rename those to
_GLIB_MAN and so on.

On second though, it looks like those variables are never used at all (see rP549741):

-post-install-MANPAGES-on:
-.for m in glib gio gobject
-       ${INSTALL_MAN} ${${m}_MAN:S|^|${WRKSRC}/docs/reference/${m}/|} \
-               ${STAGEDIR}${PREFIX}/man/man1
This revision now requires changes to proceed.Feb 13 2021, 2:28 PM
otis marked an inline comment as done.Feb 13 2021, 4:21 PM
  • Remove leftovers
  • Derive _LIBVERSION from DISTVERSION
otis marked 3 inline comments as done.Feb 13 2021, 5:10 PM
devel/glib20/Makefile
36

^ I think this is a bit too over complicated for what it does --- I would stick with the number.

This revision is now accepted and ready to land.Feb 13 2021, 6:23 PM
This revision was automatically updated to reflect the committed changes.

Couldn't find my old PR - ever since USES= ... python, I limit to build dependency only
Is there anything I miss which requires python for run-time?

Thanks

Index: devel/glib20/Makefile
===================================================================
--- devel/glib20/Makefile       (revision 565220)
+++ devel/glib20/Makefile       (working copy)
@@ -19,7 +19,7 @@
 # iconv:wchar_t - our iconv in base doesn't support utf-8 -> wchar_t (boooo)
 # (wchar_t is used by glibmm, rawtherapee triggered this)
 USES=          compiler:c11 gettext gnome iconv:wchar_t localbase:ldflags \
-               meson perl5 pkgconfig python:3.6+ tar:xz
+               meson perl5 pkgconfig python:3.6+,build tar:xz
 USE_LDCONFIG=  yes
 USE_PERL5=     build
 USE_PYTHON=    py3kplist

Couldn't find my old PR - ever since USES= ... python, I limit to build dependency only
Is there anything I miss which requires python for run-time?

Thanks

You would have to properly investigate, and make sure, that nothing of glib actually requires python at runtime. And then make sure, that nothing else that got its python transitively through glib misses python when removing it here.
I'm not convinced, that it is adviceable, but certainly doable.