graphics/gegl: make and bsd.gnome.mk its all really hosed

[Peter]

Beware, friends, 
   this will be real fun! So take a cup of tea, sit down 
and enjoy!


Everythig started when I noticed that my graphics/gegl build
ended with this error:

> ===>   Registering installation for gegl-0.1.8_1
> ===>  Building package for gegl-0.1.8_1
> tar: libdata/pkgconfig/gegl.pc: Cannot stat: No such file or directory
> tar: Error exit delayed from previous errors.
> pkg_create: make_dist: tar command failed with code 256
> *** Error code 1
> 
> Stop in /usr/ports/graphics/gegl.

That was not really funny, but it became better: Next time the 
build was run, it completed without this error!

Now let me mention a thing first: I am building ports in a chroot,
which is based on ZFS snapshots, so it can always be rolled back
to a defined state.
That also means: I am talking about well defined circumstances. 
Things that happen to happen randomly are quite strange in such
a situation.

Now, as usual, when such strange errors appear, one will suppose
that its the JOBS ('make -j') feature. So I searched into that
direction - which figured wrong later - but I found something 
there, nevertheless.

It seemed that the error would not likely appear when simply 
running "make" in the portsdir, but it would rather likely appear 
when running "make -j2". I further noticed that it was enough to
run "make -j2 patch" to trigger the error.

Now, I know there are ports that do work with -j, and there are
others that do not work. But "make patch" is not the port itself,
it is our stuff from ports/Mk, and I might suppose that should 
be solid enough to handle -j.

There is now also an interesting thing to see in the output:

> # make clean
> ===>  Cleaning for gegl-0.1.8_1
> # make -j2 patch
> find: /usr/ports/graphics/gegl/work/gegl-0.1.8: No such file or directory
> find: /usr/ports/graphics/gegl/work/gegl-0.1.8: No such file or directory
> ===>  Vulnerability check disabled, database not found
> ===>  License check disabled, port has not defined LICENSE
> ===>  Found saved configuration for gegl-0.1.8_1
> ===>  Extracting for gegl-0.1.8_1
> => SHA256 Checksum OK for gegl-0.1.8.tar.bz2.

These two "find:" warnings do not belong there, I suppose.

I went searching the "find"s, and I found the "find"s. They are
in Mk/bsd.gnome.mk, named "gnomehack_PRE_PATCH".

This does exactly what I expected: it modifies the "Makefile.in", so
that the "pkgconfig" directory is assumed below "libdata" instead
of "lib":

> --- Makefile.in.bak     2011-11-18 19:13:18.000000000 +0000
> +++ Makefile.in 2011-12-18 11:10:41.602742074 +0000
> @@ -364,7 +364,7 @@
>  # the next run of make.
>  SUBDIRS = libs gegl operations bin tools examples tests \
>         $(am__append_1)
> -pkgconfigdir = $(libdir)/pkgconfig
> +pkgconfigdir = $(prefix)/libdata/pkgconfig
>  pkgconfig_DATA = gegl.pc
>  built_dist_files = README
>  EXTRA_DIST = \


So, I fixed this one to be forced to run later, with the followning
patch.

*** ports/Mk/bsd.gnome.mk.orig  Sun Dec 18 05:55:08 2011
--- ports/Mk/bsd.gnome.mk       Sun Dec 18 05:56:31 2011
***************
*** 780,786 ****
  
  pre-patch: gnome-pre-patch
  
! gnome-pre-patch:
        @${GNOME_PRE_PATCH:C/^;//1}
  .endif
  
--- 780,786 ----
  
  pre-patch: gnome-pre-patch
  
! gnome-pre-patch: patch-dos2unix
        @${GNOME_PRE_PATCH:C/^;//1}
  .endif


At that point I thought I had caught it and am now
clear on the vortex; and started the build again.
But it got funnier: the behaviour was unchanged! It still did
occasionally work or not work, with the same error as before!

Then I figured that "make -j" was not even used for the patch step;
so, while the above patch would help people who enter "make -j" 
in the portsdir directly, it has nothing to do with the automatix
as controlled by the FORCE_MAKE_JOBS option.

But then, what the f**k was going on here?

I found another thing in the Makefile of graphics/gegl itself:

> # Disable docs until I fix the problem with graphviz's dot
> NOPORTDOCS=     yes
[...]
> post-patch:
> .if defined(NOPORTDOCS)
>         ${REINPLACE_CMD} -e '10s|\\||; 11,13d' ${WRKSRC}/Makefile.am
> .endif
        
Now, while the "gnomehack_PRE_PATCH" modifies "Makefile.in", this
one modifies "Makefile.am". Precisely, it deletes three lines from
"Makefile.am", which removes some directories from the build list:

> disp-chroot# diff -u Makefile.am.bak Makefile.am
> --- Makefile.am.bak     2011-11-18 16:00:53.000000000 +0000
> +++ Makefile.am 2011-12-18 09:59:03.065282655 +0000
> @@ -7,10 +7,7 @@
>         libs \
>         gegl \
>         operations \
> -       bin \
> -       tools \
> -       examples \
> -       tests
> +       bin 
>  
>  if ENABLE_DOCS
>  SUBDIRS+= docs

This is in some way reflected in the plist, too - but from one or
two glances it doesn't seem to me that the variables would match.

I am no specialist in matter of automake and friends, so I do not
know precisely what "Makefile.in" and "Makefile.am" are good for or 
what one can do (or not do) with them.
But then I figured an essential point of my random results:

*EITHER* these changes to "Makefile.am" get propagated to "Makefile.in"
(and finally to "Makefile"). By that, the previous change to
"Makefile.in" (that is, the correct pkgconfig path from
"gnomehack_PRE_PATCH") will be overwritten! And then the gegl.pc
file is found missing at packaging time (because it is placed into
lib/pkgconfig instead of libdata/pkgconfig).

*OR* the  "Makefile.in" is NOT overwritten. Then the changes
to "Makefile.am" have no effect and are useless! Then the "tools",
"examples" and "tests" are built and installed, and we seem to get a
bunch of files onto the system which aren't recorded in a plist.

It's broken either way. 

Finally: why does this behaviour change erratically? I can repeat a
sequence of "make clean; make" in the portsdir, and one time it's
this way and next the other!

The critical point seems to be the following operations:

> ===>  Building for gegl-0.1.8_1
> cd . && /bin/sh /usr/ports/graphics/gegl/work/gegl-0.1.8/missing --run automake-1.11 --gnu Makefile
> cd . && /bin/sh ./config.status Makefile 
> config.status: creating Makefile

These happen to happen, once, and do not happen the next time -
it seems to be dependent on some strange race. 
For my purposes, I do now:

*** ports/graphics/gegl/Makefile.orig   Sun Dec 18 15:32:58 2011
--- ports/graphics/gegl/Makefile        Sun Dec 18 15:34:59 2011
***************
*** 184,189 ****
--- 184,192 ----
        ${REINPLACE_CMD} -e 's|\(lua\)\(5\.1\)|\1-\2|g'
${WRKSRC}/configure
	${REINPLACE_CMD} -e 's|/usr/bin/ruby|/usr/bin/env ruby|'
${WRKSRC}/tools/gobj2dot.rb
  
+ pre-build:
+ 	touch ${WRKSRC}/Makefile.in
+ 
  post-build:
  .if !defined(NOPORTDOCS)
 	 cd ${WRKSRC}/docs && ${GMAKE}


This seems to give me some *defined* behaviour, at least.

To be honest, I am currently clueless on how to *correctly* fix this. 
The best idea I would imagine would be to extend the 
"gnomehack_PRE_PATCH" to not only modify "Makefile.in" but also
"Makefile.am". But as this is used by some thousand ports, it might
just be calling for more trouble...

PMc