On Fri, 2010-08-27 at 00:07 +0200, Enrico Weigelt wrote: > > > They still use the conceptionally broken AC_TRY_RUN(). [1] > > > So, the chain is broken, everything beyond that cannot be built. > > > Period. > > > > That is really a problem in your build environment then. > > No, it's a general misdesign. In 99.99% totally unncessary.
If there are unnecessary calls to AC_TRY_RUN in the glib configure script, then I suggest that you file bug reports for them and attach patches. I am pretty sure that the glib maintainers will happily accept such patches if the calls to AC_TRY_RUN can really be avoided. > > You can easily feed the expected result of AC_TRY_RUN tests > > to the configure script so that it will not attempt to run > > the tests. > > Easily ?! > > By analyzing the configure.in and all related m4 files, watch out > for the AC_TRY_RUN calls, find out what they really should do, > tweak them to produce the appropriate result - for each specific > target - w/o trying to run anything. For each single package in > all required versions. Basicly this means maintaining full > downstream-branches, one per package+version+target. > That totally undermines the whole purpose of autoconf. > > > Pretty much any decent build environment out there has > > support to build glib2. > > Which of those are doing clean crosscompiling ? > How much work to the package maintainers have to spend into > each single upstream release, per individual target configuration ? As far as I can see the effort spent in buildroot to maintain glib2 is marginal. I have done several glib2 updates myself and it pretty much boiled down to increasing the version number. It is not that glib would introduce new AC_TRY_RUN calls every now and then. There are a handful of such calls and as far as I can see they are all needed. The good thing is that once you have glib cross-compiled, you are working in an environment that allows you to write portable code without the effort of using #ifdefs and feature checks for all platforms. Sven Sven _______________________________________________ directfb-dev mailing list directfb-dev@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
