Re: poison gettext-tools

2016-10-27 Thread Stuart Henderson 
On 2016/10/17 17:54, Antoine Jacoutot wrote:
> On Mon, Oct 17, 2016 at 04:03:16PM +0100, Stuart Henderson wrote:
> > On 2016/10/17 16:41, Antoine Jacoutot wrote:
> > > On Mon, Oct 17, 2016 at 03:20:37PM +0100, Stuart Henderson wrote:
> > > > On 2016/10/17 13:49, Jeremie Courreges-Anglas wrote:
> > > > > Stuart Henderson  writes:
> > > > > 
> > > > > > I'm going to do a bulk build with this to see if it shakes anything 
> > > > > > out.
> > > > > > Any comments on whether it's worth committing?
> > > > > 
> > > > > I like the idea, but it currently doesn't behave as one would expect.
> > > > > See for example x11/xpad, which has
> > > > > 
> > > > >   MODULES=textproc/intltool
> > > > > 
> > > > > The patch shouldn't change anything since intltool brings in
> > > > > gettext-tools, but:
> > > > 
> > > > Thanks - Antoine pointed out that this will apply to GNOME as well.
> > > > 
> > > > We could check for multiple alternative ports in BUILD_DEPENDS, but
> > > > this wouldn't fit nicely with Marc's suggestion to make the framework
> > > > more general, so how about adding gettext-tools to intltool.port.mk?
> > > 
> > > If there is no other way...
> > 
> > The two options are
> > 
> > +.if !defined(BUILD_DEPENDS) || !${BUILD_DEPENDS:Mdevel/gettext-tools} && \
> > +   !${BUILD_DEPENDS:Mtextproc/intltool}
> 
> This has my vote.
> Less magic imho.

So, this has survived a dpb run (actually several runs as I had temporarily
forgotten about it) - OK?

Index: bsd.port.mk
===
RCS file: /cvs/ports/infrastructure/mk/bsd.port.mk,v
retrieving revision 1.1322
diff -u -p -r1.1322 bsd.port.mk
--- bsd.port.mk 6 Sep 2016 10:31:12 -   1.1322
+++ bsd.port.mk 18 Oct 2016 13:56:03 -
@@ -2469,6 +2469,17 @@ ${_WRKDIR_COOKIE}:
 .if !empty(WRKDIR_LINKNAME)
@ln -sf ${WRKDIR} ${.CURDIR}/${WRKDIR_LINKNAME}
 .endif
+# poison some common gettext-tools binaries
+.if !defined(BUILD_DEPENDS) || !${BUILD_DEPENDS:Mdevel/gettext-tools} && \
+   !${BUILD_DEPENDS:M*textproc/intltool}
+   printf '#!/bin/sh\n\
+   echo "*** $$0 was called without gettext-tools dependency ***" 
>&2\n\
+   exit 1\n' > ${WRKDIR}/bin/msgfmt
+   chmod 555 ${WRKDIR}/bin/msgfmt
+.  for name in msgcat msginit
+   @ln -sf msgfmt ${WRKDIR}/bin/${name}
+.  endfor
+.endif
@${_MAKE_COOKIE} $@
 
 ${_EXTRACT_COOKIE}: ${_WRKDIR_COOKIE}

Re: poison gettext-tools

2016-10-17 Thread Antoine Jacoutot 
On Mon, Oct 17, 2016 at 04:03:16PM +0100, Stuart Henderson wrote:
> On 2016/10/17 16:41, Antoine Jacoutot wrote:
> > On Mon, Oct 17, 2016 at 03:20:37PM +0100, Stuart Henderson wrote:
> > > On 2016/10/17 13:49, Jeremie Courreges-Anglas wrote:
> > > > Stuart Henderson  writes:
> > > > 
> > > > > I'm going to do a bulk build with this to see if it shakes anything 
> > > > > out.
> > > > > Any comments on whether it's worth committing?
> > > > 
> > > > I like the idea, but it currently doesn't behave as one would expect.
> > > > See for example x11/xpad, which has
> > > > 
> > > >   MODULES=textproc/intltool
> > > > 
> > > > The patch shouldn't change anything since intltool brings in
> > > > gettext-tools, but:
> > > 
> > > Thanks - Antoine pointed out that this will apply to GNOME as well.
> > > 
> > > We could check for multiple alternative ports in BUILD_DEPENDS, but
> > > this wouldn't fit nicely with Marc's suggestion to make the framework
> > > more general, so how about adding gettext-tools to intltool.port.mk?
> > 
> > If there is no other way...
> 
> The two options are
> 
> +.if !defined(BUILD_DEPENDS) || !${BUILD_DEPENDS:Mdevel/gettext-tools} && \
> + !${BUILD_DEPENDS:Mtextproc/intltool}

This has my vote.
Less magic imho.

> or adding to BUILD_DEPENDS in intltool.port.mk.
> 
> Who has which preferences? :)
> 

-- 
Antoine

Re: poison gettext-tools

2016-10-17 Thread Stuart Henderson 
On 2016/10/17 16:41, Antoine Jacoutot wrote:
> On Mon, Oct 17, 2016 at 03:20:37PM +0100, Stuart Henderson wrote:
> > On 2016/10/17 13:49, Jeremie Courreges-Anglas wrote:
> > > Stuart Henderson  writes:
> > > 
> > > > I'm going to do a bulk build with this to see if it shakes anything out.
> > > > Any comments on whether it's worth committing?
> > > 
> > > I like the idea, but it currently doesn't behave as one would expect.
> > > See for example x11/xpad, which has
> > > 
> > >   MODULES=textproc/intltool
> > > 
> > > The patch shouldn't change anything since intltool brings in
> > > gettext-tools, but:
> > 
> > Thanks - Antoine pointed out that this will apply to GNOME as well.
> > 
> > We could check for multiple alternative ports in BUILD_DEPENDS, but
> > this wouldn't fit nicely with Marc's suggestion to make the framework
> > more general, so how about adding gettext-tools to intltool.port.mk?
> 
> If there is no other way...

The two options are

+.if !defined(BUILD_DEPENDS) || !${BUILD_DEPENDS:Mdevel/gettext-tools} && \
+   !${BUILD_DEPENDS:Mtextproc/intltool}

or adding to BUILD_DEPENDS in intltool.port.mk.

Who has which preferences? :)

Re: poison gettext-tools

2016-10-17 Thread Antoine Jacoutot 
On Mon, Oct 17, 2016 at 03:20:37PM +0100, Stuart Henderson wrote:
> On 2016/10/17 13:49, Jeremie Courreges-Anglas wrote:
> > Stuart Henderson  writes:
> > 
> > > I'm going to do a bulk build with this to see if it shakes anything out.
> > > Any comments on whether it's worth committing?
> > 
> > I like the idea, but it currently doesn't behave as one would expect.
> > See for example x11/xpad, which has
> > 
> >   MODULES=textproc/intltool
> > 
> > The patch shouldn't change anything since intltool brings in
> > gettext-tools, but:
> 
> Thanks - Antoine pointed out that this will apply to GNOME as well.
> 
> We could check for multiple alternative ports in BUILD_DEPENDS, but
> this wouldn't fit nicely with Marc's suggestion to make the framework
> more general, so how about adding gettext-tools to intltool.port.mk?

If there is no other way...

-- 
Antoine

Re: poison gettext-tools

2016-10-17 Thread Stuart Henderson 
On 2016/10/17 13:49, Jeremie Courreges-Anglas wrote:
> Stuart Henderson  writes:
> 
> > I'm going to do a bulk build with this to see if it shakes anything out.
> > Any comments on whether it's worth committing?
> 
> I like the idea, but it currently doesn't behave as one would expect.
> See for example x11/xpad, which has
> 
>   MODULES=textproc/intltool
> 
> The patch shouldn't change anything since intltool brings in
> gettext-tools, but:

Thanks - Antoine pointed out that this will apply to GNOME as well.

We could check for multiple alternative ports in BUILD_DEPENDS, but
this wouldn't fit nicely with Marc's suggestion to make the framework
more general, so how about adding gettext-tools to intltool.port.mk?

Re: poison gettext-tools

2016-10-17 Thread Jeremie Courreges-Anglas 
Stuart Henderson  writes:

> I'm going to do a bulk build with this to see if it shakes anything out.
> Any comments on whether it's worth committing?

I like the idea, but it currently doesn't behave as one would expect.
See for example x11/xpad, which has

  MODULES=textproc/intltool

The patch shouldn't change anything since intltool brings in
gettext-tools, but:

ritchie /usr/ports/x11/xpad$ make
printf '#!/bin/sh\n echo "*** $0 was called without gettext-tools dependency 
***" >&2\n exit 1\n' > /usr/ports/pobj/xpad-4.0/bin/msgfmt
chmod 555 /usr/ports/pobj/xpad-4.0/bin/msgfmt
===> xpad-4.0p8 depends on: intltool->=0.41.1p0 -> intltool-0.51.0p1
===> xpad-4.0p8 depends on: gmake-* -> gmake-4.2.1
===> xpad-4.0p8 depends on: bzip2-* -> bzip2-1.0.6p8
===> xpad-4.0p8 depends on: gettext-* -> gettext-0.19.8.1
===> xpad-4.0p8 depends on: gtk+2-* -> gtk+2-2.24.31
===>  Verifying specs:  ICE SM X11 Xcomposite Xcursor Xdamage Xext Xfixes Xi 
Xinerama Xrandr Xrender atk-1.0 c cairo fontconfig freetype gdk-x11-2.0 
gdk_pixbuf-2.0 gio-2.0 glib-2.0 gobject-2.0 gtk-x11-2.0 intl pango-1.0 
pangocairo-1.0 pangoft2-1.0 pthread z
===>  found ICE.10.0 SM.9.0 X11.16.1 Xcomposite.4.0 Xcursor.5.0 Xdamage.4.0 
Xext.13.0 Xfixes.6.0 Xi.12.1 Xinerama.6.0 Xrandr.7.1 Xrender.6.0 
atk-1.0.21809.1 c.89.2 cairo.12.3 fontconfig.11.0 freetype.26.0 
gdk-x11-2.0.2400.0 gdk_pixbuf-2.0.3200.0 gio-2.0.4200.3 glib-2.0.4200.3 
gobject-2.0.4200.3 gtk-x11-2.0.2400.0 intl.6.0 pango-1.0.3800.0 
pangocairo-1.0.3800.0 pangoft2-1.0.3800.0 pthread.23.0 z.5.0
===>  Checking files for xpad-4.0p8
`/d/distfiles/xpad-4.0.tar.bz2' is up to date.
>> (SHA256) xpad-4.0.tar.bz2: OK
===>  Extracting for xpad-4.0p8
===>  Patching for xpad-4.0p8
===>   Applying OpenBSD patch patch-src_xpad-pad_c
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--
|$OpenBSD: patch-src_xpad-pad_c,v 1.1 2010/05/13 14:14:49 sthen Exp $
|
|unbreak with gtk+2.20
|
|--- src/xpad-pad.c.origThu May 13 14:23:55 2010
|+++ src/xpad-pad.c Thu May 13 14:38:28 2010
--
Patching file src/xpad-pad.c using Plan A...
Hunk #1 succeeded at 275.
done
===>  Configuring for xpad-4.0p8
Using /usr/ports/pobj/xpad-4.0/config.site (generated)
configure: WARNING: unrecognized options: --disable-silent-rules, 
--disable-gtk-doc
configure: loading site script /usr/ports/pobj/xpad-4.0/config.site
checking for a BSD-compatible install... /usr/ports/pobj/xpad-4.0/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... mkdir -p
checking for gawk... (cached) awk
checking whether gmake sets $(MAKE)... yes
checking for style of include used by gmake... GNU
checking for gcc... cc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... (cached) o
checking whether we are using the GNU C compiler... (cached) yes
checking whether cc accepts -g... (cached) yes
checking for cc option to accept ISO C89... none needed
checking dependency style of cc... gcc3
checking for /proc/self/maps... no
checking whether everything is installed to the same prefix... no
checking whether binary relocation support should be enabled... no
checking for gcc... (cached) cc
checking whether we are using the GNU C compiler... (cached) yes
checking whether cc accepts -g... (cached) yes
checking for cc option to accept ISO C89... (cached) none needed
checking dependency style of cc... (cached) gcc3
checking for a BSD-compatible install... /usr/ports/pobj/xpad-4.0/bin/install -c
checking whether gmake sets $(MAKE)... (cached) yes
checking whether NLS is requested... yes
checking for intltool >= 0.31... 0.51.0 found
checking for intltool-update... /usr/local/bin/intltool-update
checking for intltool-merge... /usr/local/bin/intltool-merge
checking for intltool-extract... /usr/local/bin/intltool-extract
checking for xgettext... /usr/local/bin/xgettext
checking for msgmerge... /usr/local/bin/msgmerge
checking for msgfmt... /usr/ports/pobj/xpad-4.0/bin/msgfmt
checking for gmsgfmt... /usr/ports/pobj/xpad-4.0/bin/msgfmt
*** /usr/ports/pobj/xpad-4.0/bin/msgfmt was called without gettext-tools 
dependency ***
configure: error: GNU gettext tools not found; required for intltool
*** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2659 
'/usr/ports/pobj/xpad-4.0/.configure_done')
*** Error 1 in /usr/ports/x11/xpad 
(/usr/ports/infrastructure/mk/bsd.port.mk:2390 'all')
ritchie /usr/ports/x11/xpad$ vi Makefile


-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

Re: poison gettext-tools

2016-10-17 Thread Marc Espie 
On Mon, Oct 17, 2016 at 09:34:49AM +0100, Stuart Henderson wrote:
> I'm going to do a bulk build with this to see if it shakes anything out.
> Any comments on whether it's worth committing?
> 
> Index: bsd.port.mk
> ===
> RCS file: /cvs/ports/infrastructure/mk/bsd.port.mk,v
> retrieving revision 1.1322
> diff -u -p -r1.1322 bsd.port.mk
> --- bsd.port.mk   6 Sep 2016 10:31:12 -   1.1322
> +++ bsd.port.mk   17 Oct 2016 08:34:27 -
> @@ -2469,6 +2469,16 @@ ${_WRKDIR_COOKIE}:
>  .if !empty(WRKDIR_LINKNAME)
>   @ln -sf ${WRKDIR} ${.CURDIR}/${WRKDIR_LINKNAME}
>  .endif
> +# poison some common gettext-tools binaries
> +.if !defined(BUILD_DEPENDS) || !${BUILD_DEPENDS:Mdevel/gettext-tools}
> + printf '#!/bin/sh\n\
> + echo "*** $$0 was called without gettext-tools dependency ***" 
> >&2\n\
> + exit 1\n' > ${WRKDIR}/bin/msgfmt
> + chmod 555 ${WRKDIR}/bin/msgfmt
> +.  for name in msgcat msginit
> + @ln -sf msgfmt ${WRKDIR}/bin/${name}
> +.  endfor
> +.endif
>   @${_MAKE_COOKIE} $@
>  
>  ${_EXTRACT_COOKIE}: ${_WRKDIR_COOKIE}
Good idea.  Maybe we'll make that more independent in the future, but
for one tool, it's good.

I would probably prefer a pattern like
.for tool dep in msgfmt devel/gettext-tools msgcat devel/gettext-tools msginit 
devel/gettext-tools
...
.endfor

but it's trivial to change later

poison gettext-tools

2016-10-17 Thread Stuart Henderson 
I'm going to do a bulk build with this to see if it shakes anything out.
Any comments on whether it's worth committing?

Index: bsd.port.mk
===
RCS file: /cvs/ports/infrastructure/mk/bsd.port.mk,v
retrieving revision 1.1322
diff -u -p -r1.1322 bsd.port.mk
--- bsd.port.mk 6 Sep 2016 10:31:12 -   1.1322
+++ bsd.port.mk 17 Oct 2016 08:34:27 -
@@ -2469,6 +2469,16 @@ ${_WRKDIR_COOKIE}:
 .if !empty(WRKDIR_LINKNAME)
@ln -sf ${WRKDIR} ${.CURDIR}/${WRKDIR_LINKNAME}
 .endif
+# poison some common gettext-tools binaries
+.if !defined(BUILD_DEPENDS) || !${BUILD_DEPENDS:Mdevel/gettext-tools}
+   printf '#!/bin/sh\n\
+   echo "*** $$0 was called without gettext-tools dependency ***" 
>&2\n\
+   exit 1\n' > ${WRKDIR}/bin/msgfmt
+   chmod 555 ${WRKDIR}/bin/msgfmt
+.  for name in msgcat msginit
+   @ln -sf msgfmt ${WRKDIR}/bin/${name}
+.  endfor
+.endif
@${_MAKE_COOKIE} $@
 
 ${_EXTRACT_COOKIE}: ${_WRKDIR_COOKIE}