On Thu, Aug 07, 2008 at 02:21:03PM +0200, Robert Millan wrote: > On Mon, Aug 04, 2008 at 08:51:25AM -0400, Pavel Roskin wrote: > > On Mon, 2008-08-04 at 11:16 +0200, Robert Millan wrote: > > > > > Furthermore, I had a look and some of the x86_64 versions are just stubs > > > that > > > include the i386 one. > > > > > > Why don't we handle this like Linux? They ship a single directory and use > > > #ifdefs where appropiate. That enforces consistency in the dir layout. > > > > I think we can do it. i386 and x86_64 could be joined into one "x86" > > architecture with common headers and sources. Perhaps the users should > > still use i386 and x86_64 in configure, but the code should be mostly > > common. > > I gave a try at this, which I haven't completed yet. Here's what I have > so far. > > The biggest stumbling block seems to be that autoconf doesn't make it easy > to do AC_CHECK_SIZEOF checks for standard compiling and cross-compiling in > the same run (it does support cross-compiling though). > > I haven't found a way to do it. If I modify types.m4 to export its > findings to a variable instead of dumping them to config.h directly, > further calls to the same check won't return different results, even if > CC / CFLAGS has been adjusted.
Somebody pointed an interesting solution to me on IRC: we could have multiple configure scripts, one for each kind of compilation. I think what would fit well in this scheme is a simple util/configure that just setups things to build native tools "the usual way", and then the main configure can: a) Invoke util/configure with the right params for native compilation b) Simplify its own arch handling logic. Thoughts? -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
