All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Roskin <proski@gnu.org>
To: Vladimir 'phcoder' Serbinenko <phcoder@gmail.com>, grub-devel@gnu.org
Subject: Re: [PATCH] enable buildable targets by default
Date: Fri, 17 Jul 2009 10:49:09 -0400	[thread overview]
Message-ID: <1247842149.25608.44.camel@mj> (raw)
In-Reply-To: <d7ead6de0907170221h1a204f75ucca48e46c1ff3611@mail.gmail.com>

On Fri, 2009-07-17 at 11:21 +0200, Vladimir 'phcoder' Serbinenko wrote:
> On Fri, Jul 17, 2009 at 2:37 AM, Pavel Roskin<proski@gnu.org> wrote:
> > Quoting Vladimir 'phcoder' Serbinenko <phcoder@gmail.com>:
> >
> >> comitted
> >
> > I wish I had time to review it :-(
> >
> > I have fixed the easy stuff (spelling, wrong variables, use of "$no",
> Thanks
> > use of "-c" in CFLAGS).
> This was done on purpose so that we don't need gcc-multilib for tests

AC_COMPILE_IFELSE already means that the program is compiled but not
linked.  I tried removing glibc-devel.i586, and everything is still OK.

> > The remaining problem is that efiemu only compiles on
> > i386-pc, but configure not only checks for the necessary flags on other
> > platforms, but also announces that it will be built.
> Actually the check is necessary only for efiemu64. Perhaps we should
> always build efiemu32 and make grub fallback to efiemu32 even on
> 64-bit platform if efiemu64 is unavailable. Then enable-efiemu would
> be renamed to enable-efiemu64

That's a separate issue.  And then there is a problem that efiemu is
undocumented, so users cannot decide whether they need it or not.

> > Perhaps we can compile efiemu on i386 and x86_64, but certainly not on
> > powerpc and sparc.
> >
> > Once everything is compiled by default, some of the configure options become
> > less meaningful, so we can consider removing them.  It's not so important to
> > disable some feature as it is to enable it.
> IMO if user does some not so useful things it's his problems. It's not
> a reason to limit flexibility

I think we should provide meaningful options.  For example, an option to
disable compiling debugging tools, or an option to add extra sanity
checks.  An option to disable efiemu64 is not meaningful for someone who
doesn't know how to use efiemu64.

-- 
Regards,
Pavel Roskin



  parent reply	other threads:[~2009-07-17 14:49 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-17 13:34 [PATCH] enable buildable targets by default Vladimir 'phcoder' Serbinenko
2009-07-16 16:39 ` Vladimir 'phcoder' Serbinenko
2009-07-17  0:37   ` Pavel Roskin
     [not found]     ` <d7ead6de0907170221h1a204f75ucca48e46c1ff3611@mail.gmail.com>
2009-07-17 14:49       ` Pavel Roskin [this message]
2009-07-18 17:55         ` Robert Millan
     [not found]           ` <d7ead6de0907181141n170ec55fueb9d0dccc365cdf3@mail.gmail.com>
2009-07-18 21:38             ` Vladimir 'phcoder' Serbinenko
2009-07-18 22:54               ` Pavel Roskin
2009-07-22 17:02                 ` Robert Millan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1247842149.25608.44.camel@mj \
    --to=proski@gnu.org \
    --cc=grub-devel@gnu.org \
    --cc=phcoder@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.