On Mon, Oct 19, 2009 at 2:53 AM, Mladen Turk <mt...@apache.org> wrote: > On 18/10/09 19:57, Jeff Trawick wrote: >> >> There is no consensus yet on the scope of what has to be addressed >> (distinct from whether the project or the packager should address it). >> The discussion in the earlier commit thread needs to be carried to >> its conclusion. >> > > What about simply making apr.h/apu.h as a stubs > for apr-$CPU.h > > eg. > > /* apr.h */ > #if defined(__i386__) > #include <apr-i386.h> > #elif define(__x86_64__) > #include <apr-x86-64.h> > etc... > > Something like that is already done on > lots of platforms to simulate the universal (multiarch) concept
or similar for SPARC or POWER or z or ... ;) This issue is already being handled by multiple packagers on multiple platforms besides Darwin, independent of the fat binary concept. I guess we could provide a helper script to aid packagers by consolidating * the list of affected header files (hopefully just apr.h/apu.h by design) * the exact mechanism, for similar experience across distributions ./helpers/merge_headers.p[ly] __i386__ /bld/32/apr-1.3.x/include/ __x86_64__ /bld/32/apr-1.3.x/include/ /inst/include Neither of these issues is a big deal, but if packagers were to make use of this it might save the users of apr a little confusion. But a set of general notes to packagers on this and other topics could be much more valuable than solving the small issue of how to use a single include directory. (I don't yet see how we can make a useful contribution on other aspects of multi-architecture support -- fat binary or multiple bin/lib/build directories or ....)
