All of lore.kernel.org
 help / color / mirror / Atom feed
From: Philip Prindeville <philipp_subx@redfish-solutions.com>
To: buildroot@busybox.net
Subject: [Buildroot] Improving buildroot
Date: Thu, 24 Jul 2008 18:39:04 -0700	[thread overview]
Message-ID: <48892EB8.7090909@redfish-solutions.com> (raw)

Hi.

I'm new to the list, but not to linux nor the idea of cross-compiling 
under Unix.

I've been using some of the buildroot work under the Astlinux project, 
which I contribute to.

I've noticed some issues with particular projects, and some recurring 
issues of a more generalized nature.

If any of this has been covered in the past, apologies for backtracking 
on old terrain.

One of the first things I noticed was that there are a lot of braindead 
configure.ac scripts out there that don't handle cross-compilation.  
That won't be of news to anyone I don't think.  The 2nd thing that I 
followed on with was that by using the appropriate --with, --without, 
--enable, --disable, and ac_cv_foo values when invoking ./configure, a 
lot of this stuff could be mitigated.

The 2nd argument to AC_CHECK_SIZEOF() is a travesty, and there's no good 
reason for having it.  It will be wrong as often as it will be right, so 
why bother having it at all?

I also noticed that some of the buildroot makefile's don't properly 
order their targets or rely on their dependencies' ages properly, so 
that doing a "make all" followed by another "make all" doesn't, in fact, 
result in "Nothing to be done for `all'" as the result... but instead a 
lot of rules are run again for no apparent reason.

I try to fix these as I encounter them, but I've not been very diligent 
about noting them.  I'll try to do better, and indeed to post my patches 
to makefiles as I find them.

So... getting back to the first issue... incorrect detection of the 
target environment's characteristics when cross-compiling...  Why don't 
we just capture most of this into a Makefile statically?

In the astlinux project, for instance, we have in one of our Makefiles 
something like:

LINUX_VERSION_MAJOR:=$(shell echo $(LINUX_VERSION) | cut -d. -f1)
LINUX_VERSION_MINOR:=$(shell echo $(LINUX_VERSION) | cut -d. -f2)
LINUX_VERSION_TRIPLE:=$(shell echo $(LINUX_VERSION) | cut -d. -f1-3)
TARGET_CONFIGURE_OPTS+=\
                ac_cv_linux_vers=$(LINUX_VERSION_MAJOR)



(yeah, it could be better written and more standardized... but it works 
for now.) and in target/device/geni586/Makefile.in:

ifeq ($(ARCH),i586)
TARGET_CONFIGURE_OPTS+=\
                ac_cv_sizeof_char=1 \
                ac_cv_sizeof_unsigned_char=1 \
                ac_cv_sizeof_short=2 \
                ac_cv_sizeof_short_int=2 \
                ac_cv_sizeof_unsigned_short=2 \
                ac_cv_sizeof_unsigned_short_int=2 \
                ac_cv_sizeof_int=4 \
                ac_cv_sizeof_long=4 \
                ac_cv_sizeof_long_int=4 \
                ac_cv_sizeof_unsigned=4 \
                ac_cv_sizeof_unsigned_int=4 \
                ac_cv_sizeof_unsigned_long=4 \
                ac_cv_sizeof_unsigned_long_int=4 \
                ac_cv_sizeof_off_t=4 \
                ac_cv_sizeof_size_t=4 \
                ac_cv_sizeof_char_p=4 \
                ac_cv_sizeof_unsigned_char_p=4 \
                ac_cv_sizeof_voidp=4 \
                ac_cv_sizeof_long_long=8 \
                ac_cv_sizeof_long_long_int=8 \
                ac_cv_sizeof_unsigned_long_long=8 \
                ac_cv_sizeof_unsigned_long_long_int=8 \
                ac_cv_sizeof_off64_t=8 \
                ac_cv_sizeof_loff_t=8
endif


Since there are a lot of broken "configure" scripts out there, and 
there's no point in having 50 or more packages try to figure out the 
native size of a "long", then why not predefine a lot of this?

What am I missing?

I'll try to go over my mods to the makefiles, and if I see anything 
useful, I'll post the diffs.

Thanks,

-Philip

             reply	other threads:[~2008-07-25  1:39 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-25  1:39 Philip Prindeville [this message]
2008-07-26  6:49 ` [Buildroot] Improving buildroot Ulf Samuelsson

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=48892EB8.7090909@redfish-solutions.com \
    --to=philipp_subx@redfish-solutions.com \
    --cc=buildroot@busybox.net \
    /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.