Re: merging i386-efi and x86_64-efi (Re: Current SVN is broken on x86_64)

[Robert Millan]

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