On Friday 13 June 2008 03:29:52 Mike Frysinger wrote:
On Thu, Jun 12, 2008 at 9:25 PM, Rob Landley wrote:
He recently converted Battle for Wesnoth to use something called scons
as its build system,
Battle of Wesnoth is currently converted to both Scons and CMake, and in the
end they will
On Friday 13 June 2008 11:12:00 you wrote:
On Fri, 2008-06-13 at 11:06 +0200, Alexander Neundorf wrote:
Why on earth does someone need this explicitly during the build?
If you have portable software, all of that should be hidden in the code
and use sizeof(int).
From the developer of
On 2008-06-12 22:52 +0500, Shaz wrote:
Hi,
I have been following Re: [PATCH 0/1] Embedded Maintainer(s) and
felt like asking that is there one good way to get a cross compiler
work. I tried buildroot, scratchbox and even openMoko with
openEmbedded but all of them had lots of issues and
On Thu, 12 Jun 2008, Robert P. J. Day wrote:
On Thu, 12 Jun 2008, Mike Frysinger wrote:
On Thu, Jun 12, 2008 at 11:50 AM, David Woodhouse wrote:
If we just made people write portable code and proper Makefiles,
it would be less of an issue :)
people cant even write proper *native*
On Thu, Jun 12, 2008 at 6:12 PM, Robert P. J. Day [EMAIL PROTECTED] wrote:
...
meooowww! :-) but at the risk of dragging this even further
off-topic, i am *constantly* asked by people how to set up makefiles
for their software project, and what would be nice is a small
collection of examples
It's nice to see we have so many options and related people and pros
to it are available around.
IMO there should be some sort of effort to standardize the tool-chains
and build environments coherently with the kernel. I think its a prime
time to work around all the possibilities and standardize
Bernd Petrovitsch wrote:
Actually the size of ints (or any other type) can be easily deduced
without running a (for the target) compiled binary:
- compile the binary (for the target) with an initialized variable with
that value.
- use cross nm (or a similar tool) to read it from there.
Or
On Thu, Jun 12, 2008 at 3:02 PM, Mike Frysinger [EMAIL PROTECTED] wrote:
people cant even write proper *native* makefiles. mtd-utils for example ;).
What's wrong with it? I'll fix it.
is [EMAIL PROTECTED] not the place to post ? that's where
i sent the first fix yesterday ... not that i'm
On Fre, 2008-06-13 at 14:17 +0100, Jamie Lokier wrote:
Bernd Petrovitsch wrote:
Actually the size of ints (or any other type) can be easily deduced
without running a (for the target) compiled binary:
- compile the binary (for the target) with an initialized variable with
that value.
-
On Thu, 2008-06-12 at 16:02 -0600, Jim Freeman wrote:
Most vendors these days have finally gotten the clue that sources/changes
have to be made available to downstream requesters, but far fewer
are sufficiently self-enlightened to figure out that changes need to
be accepted upstream for them
Hi,
I have been following Re: [PATCH 0/1] Embedded Maintainer(s) and
felt like asking that is there one good way to get a cross compiler
work. I tried buildroot, scratchbox and even openMoko with
openEmbedded but all of them had lots of issues and don't know which
will be the best
On Thu, Jun 12, 2008 at 3:02 PM, Mike Frysinger [EMAIL PROTECTED] wrote:
people cant even write proper *native* makefiles. mtd-utils for example ;).
What's wrong with it? I'll fix it.
is [EMAIL PROTECTED] not the place to post ? that's where
i sent the first fix yesterday ... not that i'm
* Samuel Robb [EMAIL PROTECTED] schrieb:
When you have a one- or two-line fix, and face Yet Another round of
finding the right mailing list, identifying the right maintainers,
figuring out the right way to submit a bug and a patch, and then have to
spend the next 3 weeks explaining how no,
Bill Traynor wrote:
Maybe I'm being dense, but what's specifically wrong with the current
toolchain universe?
Back in ye olde days, you could download GCC and Binutils from
gnu.org, configure for whatever is your architecture, and most times
it just worked.
For some reason, that stopped a
Enrico Weigelt wrote:
But: the question is whether you'll need such a test at all
or if just using sizeof() at the right place won't do the trick ;-P
It's best to do that if you can, and nearly always possible. There
are a few coding techniques - especially performance sensitive - where
that's
* Alexander Neundorf [EMAIL PROTECTED] schrieb:
In general, cross compiling is not hard. You just have to call the cross
toolchain, give it the correct parameters, search files in the right location
and ... make sure you don't test stuff by running programs.
Same with carefully written
* Jamie Lokier [EMAIL PROTECTED] schrieb:
For some reason, that stopped a while ago, and you had to go to
different places to get working basic tools. And often, the place to
go wasn't clear. Different people advertised their ARM toolchain,
m68k toolchain etc. and they were slightly
* Alexander Neundorf [EMAIL PROTECTED] schrieb:
Well, IMO this makes it sound too easy.
If you write portable software, you have to do platform checks.
Basically they can be done by
-checking for the existence of files
-checking if something builds
-checking the output of running something
Bill Traynor wrote:
Maybe I'm being dense, but what's specifically wrong with the current
toolchain universe?
Back in ye olde days, you could download GCC and Binutils from
gnu.org, configure for whatever is your architecture, and most times
it just worked.
Yes, the difficulty is in the
* Alexander Neundorf [EMAIL PROTECTED] schrieb:
E.g. in python there are tests which call functions and check
their result to see if we are currently on a platform where
that function is broken (I think there was such a test for
poll() and some other functions).
IMHO, that's broken sw
On Fre, 2008-06-13 at 17:16 +0200, Enrico Weigelt wrote:
* Bernd Petrovitsch [EMAIL PROTECTED] schrieb:
Basically yes. But if you have a big number of packages (or a huge
package)
which you didn't write yourself, there will be tests which run
executables.
Figuring out what
On Fri, Jun 13, 2008 at 05:11:04AM +0200, Sam Ravnborg wrote:
Tom has started a nice project which he named: quagmire.
See: http://code.google.com/p/quagmire/
From the website:
quagmire is intended to replace automake and libtool. Unlike these tools
it requires GNU make and is written
Bill Traynor wrote:
Do you wanna set some breakpoints and inspect variables in makefiles?
Have a look at a simple makefile debugger (written in make):
http://www.embedded.com/columns/technicalinsights/197003517?printable=true
The article above shows some macros you can add to your Makefile
On Thursday 12 June 2008 12:52:44 Shaz wrote:
Hi,
I have been following Re: [PATCH 0/1] Embedded Maintainer(s) and
felt like asking that is there one good way to get a cross compiler
work. I tried buildroot, scratchbox and even openMoko with
openEmbedded but all of them had lots of issues
On Thursday 12 June 2008 12:14:32 Bill Gatliff wrote:
Paul Mundt wrote:
Yes, that's the easy case. It's things like perl that are the corner
cases, and my objection comes from the fact that people think we ought to
not have the kernel depend on perl rather than just fixing the package
On Friday 13 June 2008 04:06:18 Alexander Neundorf wrote:
And the above are not really a big problem -
checking if something builds is no problem, this just works. Running
something is a problem, as in it doesn't just work (...because you cannot
run it).
Noticing 2 weeks after deployment
Rob,
This is an excellent and concise description of the open
source perspective on the problem. I'll add just one note below.
Rob Landley wrote:
1) Try to reproduce the bug under a current kernel. (Set up a _test_ system.)
This sounds easy, but can be quite difficult.
Very often, product
On Fri, Jun 13, 2008, Tim Bird wrote:
YMMV. I put some of the resources and info I found at:
http://elinux.org/Debugging_Makefiles
There is also remake, which is A patched GNU make with a debuger,
better tracing and error reporting (based on GNU make 3.80).
Development seems to have stopped,
Tim Bird @ Fri, 13 Jun 2008 12:06:05 -0700:
I'm running an automated test which does numerous compiles
of the Linux kernel. One of the things I do is create a localversion
file at the root of the kernel source tree with a unique identifier
that I use later on in testing.
And what kinds of
Oleg Verych wrote:
And what kinds of source/kconfig changes are made for every build?
I start with a baseline config for an embedded board, then
alter, one at a time, individual config items related to kernel size.
No source changes are made.
I do full removal of the kernel source tree and
And what kinds of source/kconfig changes are made for every build?
I start with a baseline config for an embedded board, then
alter, one at a time, individual config items related to kernel size.
No source changes are made.
Using same `gcc -E` principle, I once had a dream to create
build
Robert Schwebel wrote:
On Fri, Jun 13, 2008 at 08:30:52AM +0200, Alexander Neundorf wrote:
Battle of Wesnoth is currently converted to both Scons and CMake, and
in the end they will decide about the winner. (since Eric is good at
arguing I guess it will be scons).
The thing is that
On Fri, Jun 13, 2008 at 11:25:23PM +0100, Jamie Lokier wrote:
A trouble with that is some packages have hundreds of user-selectable
options - or even thousands.
I've not seen a package with thousands of user selectable options. It's
not even desirable, because the more options you have, the
Hi,
what are other embedded developers experience with using the
script depmod.pl from BusyBox to create
installdir/lib/modules/version/modules.dep
during compile-time?
(It's this beast:
http://busybox.net/cgi-bin/viewcvs.cgi/trunk/busybox/examples/depmod.pl?rev=20447view=markup
I tried this
Robert Schwebel wrote:
On Fri, Jun 13, 2008 at 11:25:23PM +0100, Jamie Lokier wrote:
A trouble with that is some packages have hundreds of user-selectable
options - or even thousands.
I've not seen a package with thousands of user selectable options. It's
not even desirable, because the
35 matches
Mail list logo
