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
next 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox