Sent: 2009-02-17 15:12:39 UTC (almost 3 years ago)

From: Gary V. Vaughan

babl portability patches, and a test failure

permalink

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

--
Gary V. Vaughan (gary@thewrittenword.com)

_______________________________________________
Gegl-developer mailing list
Gegl-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer

Sent: 2009-02-23 23:27:14 UTC (almost 3 years ago)

From: Sven Neumann

babl portability patches, and a test failure

permalink

Hi,

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.

> * build the extensions with libtool

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

> * 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

> * 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.

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

Yes, definitely!

Sven

Sven

_______________________________________________
Gegl-developer mailing list
Gegl-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer

Sent: 2009-02-24 04:22:12 UTC (almost 3 years ago)

From: Gary V. Vaughan

babl portability patches, and a test failure

permalink

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

--
Gary V. Vaughan (gary@thewrittenword.com)
_______________________________________________
Gegl-developer mailing list
Gegl-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer

Sent: 2009-02-24 22:19:50 UTC (almost 3 years ago)

From: Sven Neumann

babl portability patches, and a test failure

permalink

Hi,

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.

Sven

_______________________________________________
Gegl-developer mailing list
Gegl-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer

Sent: 2009-02-24 23:27:22 UTC (almost 3 years ago)

From: Sven Neumann

babl portability patches, and a test failure

permalink

Hi,

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.

Sven

Index: babl/babl-internal.h
===================================================================
--- babl/babl-internal.h (revision 394)
+++ babl/babl-internal.h (working copy)
@@ -122,7 +122,7 @@ int babl_type_is_symmetric
/* FIXME: nasty,. including the symbol even in files where it is
* not needed,. and a dummy function to use it in those cases
*/
-static BablDb *db=NULL;
+static BablDb *db = NULL;
static void hack_hack (void)
{
if (db==NULL)
@@ -135,26 +135,27 @@ static void hack_hack (void)
void babl_backtrack (void);

static inline void
-real_babl_log (const char *file,
- int line,
- const char *function,
- const char *fmt, ...)
+real_babl_logv (const char *file,
+ int line,
+ const char *function,
+ const char *fmt,
+ va_list varg)
{
- Babl *extender = babl_extender();
- va_list varg;
-
-
- if (extender != babl_extension_quiet_log())
+ if (file && function)
{
- if (babl_extender())
- fprintf (stdout, "When loading %s:\n\t", babl_extender()->instance.name);
+ Babl *extender = babl_extender();

- fprintf (stdout, "%s:%i %s()\n\t", file, line, function);
+ if (extender != babl_extension_quiet_log())
+ {
+ if (babl_extender())
+ fprintf (stdout, "When loading %s:\n\t",
+ babl_extender()->instance.name);
+
+ fprintf (stdout, "%s:%i %s()\n\t", file, line, function);
+ }
}

- va_start (varg, fmt);
vfprintf (stdout, fmt, varg);
- va_end (varg);

fprintf (stdout, "\n");
fflush (NULL);
@@ -162,14 +163,67 @@ real_babl_log (const char *file,
hack_hack ();
}

-#define babl_log(args...) \
+static inline void
+real_babl_log (const char *file,
+ int line,
+ const char *function,
+ const char *fmt,
+ ...)
+{
+ va_list varg;
+
+ va_start (varg, fmt);
+ real_babl_logv (file, line, function, fmt, varg);
+ va_end (varg);
+}
+
+#ifdef HAVE_ISO_C_VARARGS
+
+#define babl_log(...) \
+ real_babl_log(__FILE__, __LINE__, __func__, __VA_ARGS__)
+
+#define babl_fatal(...) do{ \
+ real_babl_log(__FILE__, __LINE__, __func__, __VA_ARGS__); \
+ babl_die();} \
+while(0)
+
+#elif if defined(HAVE_GNUC_VARARGS)
+
+#define babl_log(args...) \
real_babl_log(__FILE__, __LINE__, __func__, args)

-#define babl_fatal(args...) do{ \
- real_babl_log(__FILE__, __LINE__, __func__, args);\
- babl_die();} \
+#define babl_fatal(args...) do{ \
+ real_babl_log(__FILE__, __LINE__, __func__, args); \
+ babl_die();} \
while(0)

+#else /* no varargs macros */
+
+static void
+babl_log (const char *fmt,
+ ...)
+{
+ va_list args;
+
+ va_start (args, fmt);
+ real_babl_logv (NULL, 0, NULL, fmt, args);
+ va_end (args);
+}
+
+static void
+babl_fatal (const char *fmt,
+ ...)
+{
+ va_list args;
+
+ va_start (args, fmt);
+ real_babl_logv (NULL, 0, NULL, fmt, args);
+ va_end (args);
+ babl_die();
+}
+
+#endif
+

#define babl_assert(expr) do{ \
if(!(expr)) \
Index: configure.ac
===================================================================
--- configure.ac (revision 393)
+++ configure.ac (working copy)
@@ -132,12 +132,46 @@ BABL_DETECT_CFLAGS(extra_warnings, '-Wol
CFLAGS="$CFLAGS $extra_warnings"


+######################################
+# Check for flavours of varargs macros
+######################################
+
+AC_MSG_CHECKING(for ISO C99 varargs macros in C)
+AC_TRY_COMPILE([],[
+int a(int p1, int p2, int p3);
+#define call_a(...) a(1,__VA_ARGS__)
+call_a(2,3);
+], have_iso_c_varargs=yes, have_iso_c_varargs=no)
+AC_MSG_RESULT($have_iso_c_varargs)
+if test "x$have_iso_c_varargs" = "xyes"; then
+ AC_DEFINE(HAVE_ISO_C_VARARGS, 1,
+ [Define to 1 if the compiler supports ISO C99 variadic macros])
+fi
+
+AC_MSG_CHECKING(for GNUC varargs macros)
+AC_TRY_COMPILE([],[
+int a(int p1, int p2, int p3);
+#define call_a(params...) a(1,params)
+call_a(2,3);
+], have_gnuc_varargs=yes, have_gnuc_varargs=no)
+AC_MSG_RESULT($g_have_gnuc_varargs)
+if test "x$have_gnuc_varargs" = "xyes"; then
+ AC_DEFINE(HAVE_GNUC_VARARGS, 1,
+ [Define to 1 if the compiler supports GNUC variadic macros])
+fi
+
+
+################################
+# Check availability of programs
+################################
+
AC_PATH_PROG(INKSCAPE, inkscape, no)
AM_CONDITIONAL(HAVE_INKSCAPE, test "x$INKSCAPE" != "xno")

AC_PATH_PROG(W3M, w3m, no)
AM_CONDITIONAL(HAVE_W3M, test "x$W3M" != "xno")

+
###########################
# Check target architecture
###########################

_______________________________________________
Gegl-developer mailing list
Gegl-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer

Sent: 2009-02-26 13:15:46 UTC (almost 3 years ago)

From: Gary V. Vaughan

babl portability patches, and a test failure

permalink

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

--
Gary V. Vaughan (gary@thewrittenword.com)
_______________________________________________
Gegl-developer mailing list
Gegl-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer

Sent: 2009-02-26 13:45:14 UTC (almost 3 years ago)

From: Gary V. Vaughan

babl portability patches, and a test failure

permalink

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

--
Gary V. Vaughan (gary@thewrittenword.com)
_______________________________________________
Gegl-developer mailing list
Gegl-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer

Sent: 2009-02-26 19:30:57 UTC (almost 3 years ago)

From: Sven Neumann

babl portability patches, and a test failure

permalink

Hi,

On Thu, 2009-02-26 at 12:45 +0000, Gary V. Vaughan wrote:

> > 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.

Sorry, but that's how GIMP and other projects have been doing it for
more than a decade and there have never been any problems with that
approach. If there is -I$(top_srcdir) missing in the INCLUDES in some
babl Makefile, please let us know and we will add it.

If the source directory actually contains another 'config.h' then you
should hunt down the programmer who added it there and shoot him.

Sven

_______________________________________________
Gegl-developer mailing list
Gegl-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer

Sent: 2009-03-08 20:56:59 UTC (almost 3 years ago)

From: Sven Neumann

babl portability patches, and a test failure

permalink

Hi,

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?

Sven

_______________________________________________
Gegl-developer mailing list
Gegl-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer

Sent: 2009-03-10 03:46:29 UTC (almost 3 years ago)

From: Gary V. Vaughan

babl portability patches, and a test failure

permalink

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

--
Gary V. Vaughan (gary@thewrittenword.com)
_______________________________________________
Gegl-developer mailing list
Gegl-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer

Sent: 2009-03-24 22:41:26 UTC (almost 3 years ago)

From: Gary V. Vaughan

babl portability patches, and a test failure

permalink

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

--
Gary V. Vaughan (gary@thewrittenword.com)
_______________________________________________
Gegl-developer mailing list
Gegl-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer

Sent: 2009-03-25 07:09:32 UTC (almost 3 years ago)

From: Martin Nordholts

babl portability patches, and a test failure

permalink

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

- Martin

_______________________________________________
Gegl-developer mailing list
Gegl-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer

Sent: 2009-03-26 06:56:33 UTC (almost 3 years ago)

From: Gary V. Vaughan

babl portability patches, and a test failure

permalink

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

--
Gary V. Vaughan (gary@thewrittenword.com)
_______________________________________________
Gegl-developer mailing list
Gegl-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer

Sent: 2009-03-26 21:08:54 UTC (almost 3 years ago)

From: Martin Nordholts

babl portability patches, and a test failure

permalink

Gary V. Vaughan wrote:
> 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

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

- Martin

_______________________________________________
Gegl-developer mailing list
Gegl-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer

Sent: 2009-03-30 00:22:15 UTC (almost 3 years ago)

From: Gary V. Vaughan

babl portability patches, and a test failure

permalink

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

--
Gary V. Vaughan (gary@thewrittenword.com)
_______________________________________________
Gegl-developer mailing list
Gegl-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer

Sent: 2009-03-30 04:16:27 UTC (almost 3 years ago)

From: Gary V. Vaughan

babl portability patches, and a test failure

permalink

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

--
Gary V. Vaughan (gary@thewrittenword.com)
_______________________________________________
Gegl-developer mailing list
Gegl-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer

Sent: 2009-03-31 22:30:37 UTC (almost 3 years ago)

From: Martin Nordholts

babl portability patches, and a test failure

permalink

Gary V. Vaughan wrote:
> 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):

Hi,

I've done another round of commiting and this time I bumped into
problems when applying the prepare-for-gnulib patch, bot for babl and GEGL.

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.

BR,
Martin

_______________________________________________
Gegl-developer mailing list
Gegl-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer

Sent: 2009-04-02 02:49:45 UTC (almost 3 years ago)

From: Gary V. Vaughan

babl portability patches, and a test failure

permalink

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

--
Gary V. Vaughan (gary@thewrittenword.com)
_______________________________________________
Gegl-developer mailing list
Gegl-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer

Sent: 2009-04-05 17:09:50 UTC (almost 3 years ago)

From: Martin Nordholts

babl portability patches, and a test failure

permalink

Gary V. Vaughan wrote:
> Hi Martin,
>
> On Tue, Mar 31, 2009 at 10:30:37PM +0200, Martin Nordholts wrote:
>
>> I've done another round of commiting
>>
> No worries... also attached a couple more GEGL portability patches
> needed for the newest changes to git master.
>

I thought I'd give an update on this (in case you didn't receive the
bugzilla mail).

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?

- Martin

_______________________________________________
Gegl-developer mailing list
Gegl-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer

Sent: 2009-04-08 01:28:06 UTC (almost 3 years ago)

From: Gary V. Vaughan

babl portability patches, and a test failure

permalink

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

--
Gary V. Vaughan (gary@thewrittenword.com)
_______________________________________________
Gegl-developer mailing list
Gegl-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer

Sent: 2009-04-08 07:23:06 UTC (almost 3 years ago)

From: Martin Nordholts

babl portability patches, and a test failure

permalink

Gary V. Vaughan wrote:
> 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?
>>
> In my (biased) humble opinion, GNU M4 integrates the gnulib tree
> into it's git repository in a neat and easy to manage way.
>

The M4 way [1] indeed looks very nice and maintainable, could you
provide a patch for that approach please?

- Martin

[1]
http://git.savannah.gnu.org/gitweb/?p=m4.git;a=commitdiff;h=33434cee444ebefb51734ec286857e7639500ad3

_______________________________________________
Gegl-developer mailing list
Gegl-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer

Sent: 2009-04-08 08:28:00 UTC (almost 3 years ago)

From: Martin Nordholts

babl portability patches, and a test failure

permalink

Martin Nordholts wrote:
> Gary V. Vaughan wrote:
>> In my (biased) humble opinion, GNU M4 integrates the gnulib tree
>> into it's git repository in a neat and easy to manage way.
>>
>
> The M4 way [1] indeed looks very nice and maintainable, could you
> provide a patch for that approach please?

Oh, and we most likely want to wait with this until the GNOME migration
to git, which will begin April 16, is complete.

- Martin

_______________________________________________
Gegl-developer mailing list
Gegl-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer

Sent: 2009-04-25 09:14:27 UTC (almost 3 years ago)

From: Martin Nordholts

babl portability patches, and a test failure

permalink

Martin Nordholts wrote:
> Martin Nordholts wrote:
>> Gary V. Vaughan wrote:
>>> In my (biased) humble opinion, GNU M4 integrates the gnulib tree
>>> into it's git repository in a neat and easy to manage way.
>>>
>>
>> The M4 way [1] indeed looks very nice and maintainable, could you
>> provide a patch for that approach please?
>
> Oh, and we most likely want to wait with this until the GNOME
> migration to git, which will begin April 16, is complete.

Hi Gary

The git migration is now complete, how is your patch coming along?

As a starting point for Git for developers, refer to this site:
http://live.gnome.org/Git/Developer

BR,
Martin

_______________________________________________
Gegl-developer mailing list
Gegl-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer

Sent: 2009-04-25 10:36:14 UTC (almost 3 years ago)

From: David Gowers

babl portability patches, and a test failure

permalink

Hello,

On Sat, Apr 25, 2009 at 4:44 PM, Martin Nordholts wrote:
> As a starting point for Git for developers, refer to this site:
> http://live.gnome.org/Git/Developer
actually
http://live.gnome.org/Git/Developers
, FYI :)

_______________________________________________
Gegl-developer mailing list
Gegl-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer

Sent: 2009-04-25 10:40:17 UTC (almost 3 years ago)

From: Martin Nordholts

babl portability patches, and a test failure

permalink

David Gowers wrote:
> Hello,
>
> On Sat, Apr 25, 2009 at 4:44 PM, Martin Nordholts wrote:
>
>> As a starting point for Git for developers, refer to this site:
>> http://live.gnome.org/Git/Developer
>>
> actually
> http://live.gnome.org/Git/Developers
> , FYI :)
>

Oops, yes, thanks for correcting that

- Martin

_______________________________________________
Gegl-developer mailing list
Gegl-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer