It is very difficult to compile babl-0.0.22 unless you are using gcc and gmake with the GNU coreutils and ruby, on a linux host.

With the attached patches I was able to successfully build everything with the vendor compilers, and pass all but one test (failure output below) on these 30 architectures:

SuSE SLES 10 (x86_64 and i686); Redhat RHEL3, RHEL4 and RHEL5 (x86_64 and i686); Redhat 7.1, 9 and RHEL 2.1 (i686); Solaris 10 (x86 and sparc);
Solaris 2.6, 7, 8 and 9 (sparc);
AIX 4.3.3, 5.1, 5.2, 5.3 and 6.1 (powerpc); HPUX 11.31 (ia64);
HPUX 11.23 (pa-risc and ia64);
HPUX 10.20, 11.0 and 11.11 (pa-risc); IRIX 6.5 (mips);
Tru64 Unix 5.1 (ev5).

Here is a list of some of the problems solved by the attached patches, which would otherwise prevent proper compilation by one or more vendor C compilers:

* build the extensions with libtool * support '.sl' shared library ext on HPUX * use correct includedir entry in babl.pc * use gnulib stdint.h for systems that don't have one * support shl_load -ldl library loader on HPUX * remove extraneous trailing commas from *CONVERSION mcros * automake INCLUDES is deprecated, use AM_CPPFLAGS * support srcdir != builddir builds * use automake source file inference in tests/ * pregenerate changelog.rss (ruby is not commonly installed) * don't double #include
* variadic macros are not portable
* don't use non-constant struct initializers * don't use the MSB of a signed integer type in an enum * don't use C++ comments
* rewrite xml_instert.sh not to rely on GNU coreutils * for gnulib and autoconf to work properly, every .c file needs to #include before anything else!

I also wrapped the body of BABL_DETECT_CFLAGS in a GCC test, since some vendor compilers simply warn and ignore unknown flags. It would be better to fix this properly.

Correct compilation on Tru64 relies on use of the -ieee flag to cc, which I passed manually. It would be better to detect this at configure time with a correctly implemented BABL_DETECT_CFLAGS macro.

I regenerated the autotools files with latest released versions of autoconf, automake and libtool which results in a huge diff, not attached!

I also removed the babl-0.0 include subdirectory and some other instances of the @API-VERSION@, which are superflous for our installations (each package already installs to /opt/fsw/@pkg@-@version@/), but is almost certainly the wrong thing to do in upstream releases.

With these patches applied, all hosts (except linux) always fail the final test case. I'm not sure whether this is an anticipated rounding error that the test itself should be tolerant of, or if there is a genuine problem with all of the non-linux builds?

PASS: grayscale_to_rgb PASS: rgb_to_bgr
PASS: rgb_to_ycbcr
PASS: srgb_to_lab_u8
PASS: sanity
PASS: babl_class_name
PASS: types
R'G'B'
test: 60323.989 75673.805 55655.807 10508.764 clipped: 60324.000 75673.819 55655.817 1.000 trnsfrmd: 60324.010 75673.832 55655.827 1.000 R'G'B'
test: 22002.791 20097.686 55166.163 25341.894 clipped: 22002.794 20097.689 55166.173 1.000 trnsfrmd: 22002.798 20097.693 55166.182 1.000 R'G'B'
test: 31145.225 44052.134 43954.156 9807.322 clipped: 31145.230 44052.142 43954.163 1.000 trnsfrmd: 31145.235 44052.149 43954.171 1.000 R'G'B'
test: 21854.712 45827.089 6242.623 90425.124 clipped: 21854.716 45827.097 6242.624 1.000 trnsfrmd: 21854.719 45827.105 6242.624 1.000 R'G'B' is not symmetric
R'G'B'A
test: 60323.989 75673.805 55655.807 10508.764 clipped: 60324.000 75673.819 55655.817 10508.764 trnsfrmd: 60324.010 75673.832 55655.827 10508.764 R'G'B'A
test: 22002.791 20097.686 55166.163 25341.894 clipped: 22002.794 20097.689 55166.173 25341.894 trnsfrmd: 22002.798 20097.693 55166.182 25341.894 R'G'B'A
test: 31145.225 44052.134 43954.156 9807.322 clipped: 31145.230 44052.142 43954.163 9807.322 trnsfrmd: 31145.235 44052.149 43954.171 9807.322 R'G'B'A
test: 21854.712 45827.089 6242.623 90425.124 clipped: 21854.716 45827.097 6242.624 90425.124 trnsfrmd: 21854.719 45827.105 6242.624 90425.124 R'G'B'A is not symmetric
R'aG'aB'aA
test: 60323.989 75673.805 55655.807 10508.764 clipped: 60324.000 75673.819 55655.817 10508.764 trnsfrmd: 60324.010 75673.832 55655.827 10508.764 R'aG'aB'aA
test: 22002.791 20097.686 55166.163 25341.894 clipped: 22002.794 20097.689 55166.173 25341.894 trnsfrmd: 22002.798 20097.693 55166.182 25341.894 R'aG'aB'aA
test: 31145.225 44052.134 43954.156 9807.322 clipped: 31145.230 44052.142 43954.163 9807.322 trnsfrmd: 31145.235 44052.149 43954.171 9807.322 R'aG'aB'aA
test: 21854.712 45827.089 6242.623 90425.124 clipped: 21854.716 45827.097 6242.624 90425.124 trnsfrmd: 21854.719 45827.105 6242.624 90425.124 R'aG'aB'aA is not symmetric
Y'
test: 60323.989 75673.805 55655.807 10508.764 clipped: 68802.171 68802.171 68802.171 1.000 trnsfrmd: 68802.183 68802.183 68802.183 1.000 Y'
test: 22002.791 20097.686 55166.163 25341.894 clipped: 24665.123 24665.123 24665.123 1.000 trnsfrmd: 24665.127 24665.127 24665.127 1.000 Y'
test: 31145.225 44052.134 43954.156 9807.322 clipped: 40181.806 40181.806 40181.806 1.000 trnsfrmd: 40181.813 40181.813 40181.813 1.000 Y'
test: 21854.712 45827.089 6242.623 90425.124 clipped: 34146.725 34146.725 34146.725 1.000 trnsfrmd: 34146.731 34146.731 34146.731 1.000 Y' is not symmetric
Y'A
test: 60323.989 75673.805 55655.807 10508.764 clipped: 68802.171 68802.171 68802.171 10508.764 trnsfrmd: 68802.183 68802.183 68802.183 10508.764 Y'A
test: 22002.791 20097.686 55166.163 25341.894 clipped: 24665.123 24665.123 24665.123 25341.894 trnsfrmd: 24665.127 24665.127 24665.127 25341.894 Y'A
test: 31145.225 44052.134 43954.156 9807.322 clipped: 40181.806 40181.806 40181.806 9807.322 trnsfrmd: 40181.813 40181.813 40181.813 9807.322 Y'A
test: 21854.712 45827.089 6242.623 90425.124 clipped: 34146.725 34146.725 34146.725 90425.124 trnsfrmd: 34146.731 34146.731 34146.731 90425.124 Y'A is not symmetric
Y'aA
test: 60323.989 75673.805 55655.807 10508.764 clipped: 68802.171 68802.171 68802.171 10508.764 trnsfrmd: 68802.183 68802.183 68802.183 10508.764 Y'aA
test: 22002.791 20097.686 55166.163 25341.894 clipped: 24665.123 24665.123 24665.123 25341.894 trnsfrmd: 24665.127 24665.127 24665.127 25341.894 Y'aA
test: 31145.225 44052.134 43954.156 9807.322 clipped: 40181.806 40181.806 40181.806 9807.322 trnsfrmd: 40181.813 40181.813 40181.813 9807.322 Y'aA
test: 21854.712 45827.089 6242.623 90425.124 clipped: 34146.725 34146.725 34146.725 90425.124 trnsfrmd: 34146.731 34146.731 34146.731 90425.124 Y'aA is not symmetric
Y'CbCr
test: 60323.989 75673.805 55655.807 10508.764 clipped: 60323.989 75673.855 55655.819 1.000 trnsfrmd: 60323.988 75673.904 55655.832 1.000 Y'CbCr
test: 22002.791 20097.686 55166.163 25341.894 clipped: 22002.810 20097.691 55166.172 1.000 trnsfrmd: 22002.829 20097.696 55166.181 1.000 Y'CbCr
test: 31145.225 44052.134 43954.156 9807.322 clipped: 31145.230 44052.178 43954.166 1.000 trnsfrmd: 31145.235 44052.222 43954.176 1.000 Y'CbCr
test: 21854.712 45827.089 6242.623 90425.124 clipped: 21854.693 45827.155 6242.625 1.000 trnsfrmd: 21854.673 45827.221 6242.628 1.000 Y'CbCr is not symmetric
Y'CbCrA
test: 60323.989 75673.805 55655.807 10508.764 clipped: 60323.989 75673.855 55655.819 10508.764 trnsfrmd: 60323.988 75673.904 55655.832 10508.764 Y'CbCrA
test: 22002.791 20097.686 55166.163 25341.894 clipped: 22002.810 20097.691 55166.172 25341.894 trnsfrmd: 22002.829 20097.696 55166.181 25341.894 Y'CbCrA
test: 31145.225 44052.134 43954.156 9807.322 clipped: 31145.230 44052.178 43954.166 9807.322 trnsfrmd: 31145.235 44052.222 43954.176 9807.322 Y'CbCrA
test: 21854.712 45827.089 6242.623 90425.124 clipped: 21854.693 45827.155 6242.625 90425.124 trnsfrmd: 21854.673 45827.221 6242.628 90425.124 Y'CbCrA is not symmetric
FAIL: models
===================
1 of 8 tests failed
===================

If I can provide clarification for the necessity of any of the changes I made, or if a complete tarball with patches preapplied would be useful, or if you would like me to test a prerelease version with some of these fixes already applied, please don't hesitate to ask.

Thanks for your work on BABL and GEGL!

Cheers, Gary

On Mon, Feb 23, 2009 at 11:27:14PM +0100, Sven Neumann wrote:

Hi,

Hi Sven,

On Tue, 2009-02-17 at 14:12 +0000, Gary V. Vaughan wrote:

It is very difficult to compile babl-0.0.22 unless you are using gcc and gmake with the GNU coreutils and ruby, on a linux host.

With the attached patches I was able to successfully build everything with the vendor compilers, and pass all but one test (failure output below) on these 30 architectures:

SuSE SLES 10 (x86_64 and i686); Redhat RHEL3, RHEL4 and RHEL5 (x86_64 and i686); Redhat 7.1, 9 and RHEL 2.1 (i686); Solaris 10 (x86 and sparc);
Solaris 2.6, 7, 8 and 9 (sparc);
AIX 4.3.3, 5.1, 5.2, 5.3 and 6.1 (powerpc); HPUX 11.31 (ia64);
HPUX 11.23 (pa-risc and ia64);
HPUX 10.20, 11.0 and 11.11 (pa-risc); IRIX 6.5 (mips);
Tru64 Unix 5.1 (ev5).

Nice work. But unfortunately that i a huge pile of changes in more or less one large patch. You don't happen to be able to provide this as a changeset broken up into smaller changes? Some of the changes are definitely good, but we might want to handle a few things differently.

We have a system for maintaining platform patches under standard names in quilt for each package we build, which is unfortunately optimised to make best use of our time when it comes to porting the changes forward to new upstream releases... and less useful for passing patches back to developers :(

I'm sorry I don't have time to create a series of individual self- contained changesets, though I'd be happy to run prereleases through our build system, and resubmit the patches necessary for successful compilation on our machines.

* build the extensions with libtool

I think that is IMO a good idea even though it will increase build time significantly.

Also, libtool is able to build the extensions on many of the hosts above that were not supported by the existing Makefile rules.

* variadic macros are not portable

As a result you made the babl_log() macro a lot more difficult to use. IMO we should rather add a test for variadic macros to the configure script (this can be copied from glib's configure.in) and then define babl_log() similar to what GLib does in gmessages.h:

#ifdef G_HAVE_ISO_VARARGS #define g_message(...) g_log (G_LOG_DOMAIN, \ G_LOG_LEVEL_MESSAGE, \ __VA_ARGS__) #else if defined(G_HAVE_GNUC_VARARGS) #define g_message(format...) g_log (G_LOG_DOMAIN, \ G_LOG_LEVEL_MESSAGE, \ format) #else
g_message (const gchar *format,
...)
{
va_list args;
va_start (args, format);
g_logv (G_LOG_DOMAIN, G_LOG_LEVEL_MESSAGE, format, args); va_end (args);
}
#endif

Most definitely. I simply made the fastest changes I could for successful compilation. I'm sure there are technically better means to implement several of the changes I made! :)

* don't use C++ comments

That is OK. But I saw that your patch removes comments in some places. That is not OK, they should be converted to /* ... */ comments instead.

Agreed. That was laziness on my part. Sorry.

* for gnulib and autoconf to work properly, every .c file needs to #include before anything else!

Yes, definitely!

And I even kept that in a separate patch! :)

Cheers, Gary

Hi Sven,

Thanks for following up on this.

On Tue, Feb 24, 2009 at 11:27:22PM +0100, Sven Neumann wrote:

attached is a patch for babl_log. I am not too happy with the outcome as it will result in less informative log output on platforms that don't support variadic macros. But I guess that's somewhat hard to avoid and hopefully the most important platforms will support this feature. I'd appreciate feedback on this patch.

I also ported glibs variadic macro detection into babl, and gegl, while splitting up my original sumo-patch to port forward to the SVN HEAD(s). Unfortunately, it still doesn't work quite right on our older machines as is, but I'll upload the fully ported and tested version (along with my other patches) to GNOME's bugzilla after the weekend.

Please consider waiting until you've seen that patch before you commit anything.

Cheers,
Gary

Hi Sven,

On Tue, Feb 24, 2009 at 10:19:50PM +0100, Sven Neumann wrote:

On Tue, 2009-02-24 at 03:22 +0000, Gary V. Vaughan wrote:

* for gnulib and autoconf to work properly, every .c file needs to #include before anything else!

Yes, definitely!

And I even kept that in a separate patch! :)

I have committed that part to trunk now. Actually, I changed it to include "config.h" as that's more correct than . After all we are not including a system header here but a local one.

In this case, that's not the best thing to do (witness the contents of gnulib as an example). Here's the relevant reasoning from the autoconf info manual:

To provide for VPATH builds, remember to pass the C compiler a `-I.' option (or `-I..'; whichever directory contains `config.h'). Even if you use `#include "config.h"', the preprocessor searches only the directory of the currently read file, i.e., the source directory, not the build directory.

With the appropriate `-I' option, you can use `#include '. Actually, it's a good habit to use it, because in the rare case when the source directory contains another `config.h', the build directory should be searched first.

I actually tripped over that very error while testing srcdir!=builddir (aka VPATH) builds with my patches.

Cheers,
Gary

Hi Sven,

On Sun, Mar 08, 2009 at 08:56:59PM +0100, Sven Neumann wrote:

On Tue, 2009-02-24 at 23:27 +0100, Sven Neumann wrote:

attached is a patch for babl_log. I am not too happy with the outcome as it will result in less informative log output on platforms that don't support variadic macros. But I guess that's somewhat hard to avoid and hopefully the most important platforms will support this feature. I'd appreciate feedback on this patch.

Gary, I exptected some feedback, but didn't hear from you. Are you not any longer interested to get the babl portability problems solved?

Sorry, I've been offline for the last week (moving from Thailand to New Zealand).

I've split apart my patches, and ported them to today's git master branch, and am in the process of uploading them to bugzilla.gnome.org.

Cheers, Gary

Hi Sven,

On Tue, Mar 10, 2009 at 02:46:29AM +0000, Gary V. Vaughan wrote:

On Sun, Mar 08, 2009 at 08:56:59PM +0100, Sven Neumann wrote:

On Tue, 2009-02-24 at 23:27 +0100, Sven Neumann wrote:

attached is a patch for babl_log. I am not too happy with the outcome as it will result in less informative log output on platforms that don't support variadic macros. But I guess that's somewhat hard to avoid and hopefully the most important platforms will support this feature. I'd appreciate feedback on this patch.

Gary, I exptected some feedback, but didn't hear from you. Are you not any longer interested to get the babl portability problems solved?

I've split apart my patches, and ported them to today's git master branch, and am in the process of uploading them to bugzilla.gnome.org.

Has anyone been able to find time to look at my patch queue for babl?

http://bugzilla.gnome.org/show_bug.cgi?id=574705

I've also uploaded a similar patch queue for gegl itself, though I'm still unable to get it working on 2 of the 30 architectures we support:

http://bugzilla.gnome.org/show_bug.cgi?id=576615

If there's anything else I should do to help shepherd these patches into the trunk, please let me know.

Cheers, Gary

On Wed, Mar 25, 2009 at 07:09:32AM +0100, Martin Nordholts wrote:

Gary V. Vaughan wrote:

Has anyone been able to find time to look at my patch queue for babl?

I will look at them asap

Awsome :) Many thanks.

Cheers, Gary

Hi Martin,

On Thu, Mar 26, 2009 at 09:08:54PM +0100, Martin Nordholts wrote:

I've updated the babl and GEGL bug reports now with status on what patches that have been commited and where I am currently stuck

Excellent, thanks for that. I will have time to look at that early next week... and I'll post on this thread when I'm done.

Cheers, Gary

Hi Martin,

On Sun, Mar 29, 2009 at 10:22:15PM +0000, Gary V. Vaughan wrote:

On Thu, Mar 26, 2009 at 09:08:54PM +0100, Martin Nordholts wrote:

I've updated the babl and GEGL bug reports now with status on what patches that have been commited and where I am currently stuck

Excellent, thanks for that. I will have time to look at that early next week... and I'll post on this thread when I'm done.

Actually, the changes required for everything to apply cleanly to git master were trivial for both babl and GEGL, so I've uploaded all the updated patches to bugzilla again already (as attachments to the original bug reports):

http://bugzilla.gnome.org/show_bug.cgi?id=574705 http://bugzilla.gnome.org/show_bug.cgi?id=576615

I still have one consistent test failure on all non-linux hosts with babl+my_patches, and SEGV in the testsuite for GEGL+my_patches on RH Linux 7.1 and OSF/5.1... but I'll post about those separately next week.

Cheers,
Gary

Hi Martin,

On Tue, Mar 31, 2009 at 10:30:37PM +0200, Martin Nordholts wrote:

I've done another round of commiting

Awesome! Thanks again :)

and this time I bumped into
problems when applying the prepare-for-gnulib patch, bot for babl and GEGL.

I've explained how to make that work at bugzilla.

Could you look into that please? Info is in the bug reports. I suspect it will be pretty straightforward to fix for the author of the patch.

No worries... also attached a couple more GEGL portability patches needed for the newest changes to git master.

Cheers, Gary

Hi Martin,

On Sun, Apr 05, 2009 at 05:09:50PM +0200, Martin Nordholts wrote:

The only thing I can see missing now is taking care of invoking gnulib-tool --update properly in autogen.sh and provide a helpful message why this fails, if it fails.

Is there any de facto standard way of doing this?

No, there isn't.

Worse, there's a good argument for committing gnulib files to the repository so that churn in the upstream gnulib repository doesn't foil testing of client projects where several developers ran gnulib-tool from different versions of gnulib. There's also the issue of how to keep track of which gnulib version contributed to released client software.

You ought to come up with a policy decision for how gnulib will be employed in babl and GEGL before implementing the process. There is a list of projects that already use gnulib here:

http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob_plain;f=users.txt;hb=HEAD

You could look at some of these for inspiration for how other projects have integrated gnulib code into their repositories. In my (biased) humble opinion, GNU M4 integrates the gnulib tree into it's git repository in a neat and easy to manage way.

Cheers, Gary