patches for xerces on GNU/kFreeBSD (fwd)

[Guillem Jover]

Hi,

On Mon, Oct 24, 2005 at 06:32:54PM +0200, Robert Millan wrote:
> On Mon, Oct 24, 2005 at 02:23:39PM +0200, Petr Salinger wrote:
> > $ ls xerces-c-src_2_6_0/src/xercesc/util/Platforms
> > AIX  BeOS  Cygwin  FreeBSD  HPUX  IRIX  Interix  Linux  MacOS  Makefile.in  
> > NetBSD  OS2  OS390  OS400  OpenServer  PTX  QNX  Solaris  Tandem  Tru64  UnixWare  Win32
> 
> There are many packages whose upstream does this, but it's bogus.  It worked
> well for stand-alone systems that are mostly different one from each other,
> but for hybrids based on Glibc and GNUish/etc userland, most of the system
> is the same.

Even on Linux we have uClibc, dietlibc, klibc and different userland, so
the Right Thing (tm), is to check for specific functionallity and not
for the system.

> Since this program doesn't (apparently) need to interact with kernel-specific
> interfaces, it can probably be ported with just changing a pair of lines.

> For example, postgresql was ported with only changing one line:
> 
>   http://glibc-bsd.alioth.debian.org/patches/debian-only/postgresql.bash
> 
>   (this kind of change is quite typical, you can browse the directory
>    for more)

Well I consider this kind of change bogus as well. It's acceptable as a
debian specific patch but not for upstream. With this kind of patch we
are making the confusion worse.

> > * util/AutoSense.hpp depends directly  on __linux__ 

> Does AutoSense.hpp depend on Linux-specific stuff?  It's a common mistake to
> depend on Glibc-specific stuff and use __linux__ to conditionalise that.

Right.

> > But the problem of code unsynchronisation can be partially addressed:
> > * Linux/LinuxPlatformUtils.cpp will include <sys/param.h> instead of <linux/limits.h>
> > * KFreeBSD/KFreeBSDPlatformUtils.cpp then can be changed into #include "../Linux/LinuxPlatformUtils.cpp"
> 
> Sounds good.  For the latter, perhaps it's not needed if you keep "-plinux"
> flag.  In any case, if you copy code in a new place, then maintainers of this
> package (who probably don't use GNU/kFreeBSD ;) won't bother to update it when
> something changes, and the package will eventualy break.  I've seen this
> happening before and it's a mess.

But not this. It's completely wrong to do this, even if it's less work
and have more chances of being integrated upstream. For whatever
reason this package could start depending on kernel specific
interfaces and then that would break for us. In this case I'd
recommend renaming to GNU, GLibC or similar, to note what this
platform depends on.

regards,
guillem