On Tuesday 17 June 2008 15:46:36 Enrico Weigelt wrote:
> * Alexander Neundorf <[EMAIL PROTECTED]> schrieb:
> > On Monday 16 June 2008 17:15:37 Enrico Weigelt wrote:
> > > * Alexander Neundorf <[EMAIL PROTECTED]> schrieb:
> > > > CMake has a cache, where the values of variables are stored, e.g. if
>
* Adrian Bunk <[EMAIL PROTECTED]> schrieb:
Hi,
> > I won't to that w/ my TreeBuild. It is intentionally limited on
> > easily structured packages. People should either structure their
> > packages properly use something else ;-P
>
> For simple packages autoconf+automake+libtool is already near a
* Alexander Neundorf <[EMAIL PROTECTED]> schrieb:
> On Monday 16 June 2008 17:15:37 Enrico Weigelt wrote:
> > * Alexander Neundorf <[EMAIL PROTECTED]> schrieb:
> > > CMake has a cache, where the values of variables are stored, e.g. if an
> > > option is enabled or not, or where a library has been f
On Monday 16 June 2008 17:15:37 Enrico Weigelt wrote:
> * Alexander Neundorf <[EMAIL PROTECTED]> schrieb:
> > CMake has a cache, where the values of variables are stored, e.g. if an
> > option is enabled or not, or where a library has been found (e.g.
> > JPEG_LIBRARY=/usr/local/lib/libjpeg.so).
>
On Mon, Jun 16, 2008 at 11:28:36PM +0100, Jamie Lokier wrote:
> Bernhard Fischer wrote:
> > On Mon, Jun 16, 2008 at 02:32:01PM +0100, Jamie Lokier wrote:
> >
> > >No, I'm talking about improving Autotools to handle some things better
> > >than they do now. Passing the high hurdles required to bec
Bernhard Fischer wrote:
> On Mon, Jun 16, 2008 at 02:32:01PM +0100, Jamie Lokier wrote:
>
> >No, I'm talking about improving Autotools to handle some things better
> >than they do now. Passing the high hurdles required to become part of
> >Autotools - especially compatibility - is part of the goa
On Mon, Jun 16, 2008 at 06:00:37PM +0200, Enrico Weigelt wrote:
> * Alexander Neundorf <[EMAIL PROTECTED]> schrieb:
>
> > > That's why I prefer an purely descriptive paragidm (= subset of
> > > delcarative, but practically no logic): a buildfile should only
> > > describe the package's structure (
On Mon, Jun 16, 2008 at 12:52:18PM +0100, Jamie Lokier wrote:
>The same applications are fine if pread returns ENOSYS and they know
>what they need to do with lseek and read.
Note that they (pread, etc.) would better not exist at all instead of
being stubbed out (this requirement was dropped, AFA
On Mon, Jun 16, 2008 at 02:32:01PM +0100, Jamie Lokier wrote:
>No, I'm talking about improving Autotools to handle some things better
>than they do now. Passing the high hurdles required to become part of
>Autotools - especially compatibility - is part of the goal.
If you look at the sh scripts
* Alexander Neundorf <[EMAIL PROTECTED]> schrieb:
> > That's why I prefer an purely descriptive paragidm (= subset of
> > delcarative, but practically no logic): a buildfile should only
> > describe the package's structure (eg.: "i have some executable foo
> > which consists of source [...] and im
* Alexander Neundorf <[EMAIL PROTECTED]> schrieb:
> CMake has a cache, where the values of variables are stored, e.g. if an
> option
> is enabled or not, or where a library has been found (e.g.
> JPEG_LIBRARY=/usr/local/lib/libjpeg.so).
> The way to influence the behaviour of cmake is to change
Alexander Neundorf wrote:
> On Monday 16 June 2008 13:39:46 you wrote:
> ...
> > > > If you're going to rewrite Autotools using GNU Make, why not ask if
> > > > another tool would be better, perhaps a tool specially designed for
> > > > the job?
> > >
> > > Go ahead.
> >
> > The first part of going
On Monday 16 June 2008 13:39:46 you wrote:
...
> > > If you're going to rewrite Autotools using GNU Make, why not ask if
> > > another tool would be better, perhaps a tool specially designed for
> > > the job?
> >
> > Go ahead.
>
> The first part of going ahead is to brainstorm and find ideas and
>
On Mon, 2008-06-16 at 12:52 +0100, Jamie Lokier wrote:
> E.g. Calls to pread should _not_ be implemented as lseek+read+lseek on
> old kernels which don't have pread. That leads to race conditions and
> corruption in some applications. (I think this has really occurred,
> but I'm unable to find it
David Woodhouse wrote:
> On Mon, 2008-06-16 at 11:49 +0100, Jamie Lokier wrote:
> > But here's the thing: do you really want every package have code
> > calling every different variation on a system call, at run time, until
> > it finds one that works?
>
> No. That functionality lives in libc, if
Enrico Weigelt wrote:
> > Imho, Kconfig would be good for more programs than it's currently used for,
> > and could be made to work with those --enable/--with options: you'd be
> > able to configure them entirely on the command line, or interactively
> > with "./configure --menu" (runs menuconfig),
Enrico Weigelt wrote:
> > Reality is that Kconfig front end to autotools does work - as you've
> > proved. It's a good idea. :-)
>
> Now, we just need an autoconf-alike frontend for Kconfig ;-)
I agree and would support:
./configure --menu
Invokes a configuration menu / wizard for
Robert Schwebel wrote:
> We have once tried to write our automated test system for embedded
> boards with python and xml; the idea was to have something fancy, new
> and with good code-reuse. In the end it failed because the pexpect
> package we used to do the pattern matching bitrotted so quickly
On Mon, 2008-06-16 at 11:49 +0100, Jamie Lokier wrote:
> But here's the thing: do you really want every package have code
> calling every different variation on a system call, at run time, until
> it finds one that works?
No. That functionality lives in libc, if you want it at all.
--
dwmw2
--
Enrico Weigelt wrote:
> Most times I've seen those checks, they silently enable some
> features, eg. if it looks for certain kernel devices. Definitively
> the wrong way!
Agreed. Though, you do often have to check for headers etc.,
otherwise you won't have the definitions needed to work with tho
On Friday 13 June 2008 20:51:57 you wrote:
...
> Been there, seen that. I maintain > 500 packets in PTXdist and guess
> which ones make 90% of the problems. Hint: they are not related to
> autotools ...
If there are specific problems common to many cmake based packages please
report that to [EMAI
On Monday 16 June 2008 01:12:41 Enrico Weigelt wrote:
> * Robert Schwebel <[EMAIL PROTECTED]> schrieb:
>
> Hi,
>
> > Instead of hacking around and inventing new things, you should have
> > spent your time for improving libtool ...
>
> No, not with libtool.
> I do not want to support that insane app
On Friday 13 June 2008 16:51:19 Enrico Weigelt wrote:
...
> That's why I prefer an purely descriptive paragidm (= subset of
> delcarative, but practically no logic): a buildfile should only
> describe the package's structure (eg.: "i have some executable foo
> which consists of source [...] and imp
On Saturday 14 June 2008 01:19:32 you wrote:
...
> I still don't understand why all the scons, cmakes and jams out there
> don't even try to provide the *standard* user interface everyone is used
> to on a unix system.
For cmake:
CMake has a cache, where the values of variables are stored, e.g. if
* Jamie Lokier <[EMAIL PROTECTED]> schrieb:
> Media players with lots of optional formats and drivers are another.
> (They also have considerable problems with their Autoconf in my
> experience).
You probably mean their hand-written ./configure script, which is
intentionally incompatible w/ autoc
* Jamie Lokier <[EMAIL PROTECTED]> schrieb:
> A trouble with that is some packages have hundreds of user-selectable
> options - or even thousands. It is unfeasible to use --enable-foo
> options for all of those when configuring then.
Well, not that much ;-o
But taking care of such feature switch
* Robert Schwebel <[EMAIL PROTECTED]> schrieb:
> 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 scon
* Jamie Lokier <[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).
> >
> > IMH
On Thursday 12 June 2008 13:34:21 Enrico Weigelt wrote:
> * Bill Gatliff <[EMAIL PROTECTED]> schrieb:
> > If the build system derives from autoconf, then a hacked-up
> > config.cache (or equivalent command-line args) often solves
> > problems for me.
>
> Only if you're working on *one specific* tar
* Robert Schwebel <[EMAIL PROTECTED]> schrieb:
Hi,
> Instead of hacking around and inventing new things, you should have
> spent your time for improving libtool ...
No, not with libtool.
I do not want to support that insane approach of tweaking command
lines in the middle - it's an Pandorra's B
On Sat, Jun 14, 2008 at 01:07:49AM +0100, Jamie Lokier wrote:
> Kernels, uclibc, busybox. All combinations can't be tested. But it's
> still _very_ useful to compile in only those parts wanted.
Kernel (and thus kconifg) is a critical mass project of it's own;
however, kconfig does only solve the
Enrico Weigelt wrote:
> * 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
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, becaus
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 mo
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 th
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 st
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 depl
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
> 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 you
On Fri, Jun 13, 2008 at 11:44:54AM -0700, Tim Bird wrote:
> 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=tr
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 'configure && make && make insta
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
On Thu, Jun 12, 2008 at 08:37:35PM +0200, Enrico Weigelt wrote:
> ACK. One of the first things I did was replacing libtool and
> kicked off broken-by-design macros like AC_TRY_RUN. This solved
> at >80% of the problems for me.
Instead of hacking around and inventing new things, you should have
spe
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 Makefi
> On Fri, 2008-06-13 at 10:02 -0500,
> [EMAIL PROTECTED] wrote:
>> Do you wanna set some breakpoints and inspect variables in makefiles?
>> Have a look at a simple makefile debugger (written in make):
>> http://newsletter.embedded.com/shared/printableArticle.jhtml?articleID=197003517
>
> 404.
Is t
On Fri, 2008-06-13 at 10:02 -0500,
[EMAIL PROTECTED] wrote:
> Do you wanna set some breakpoints and inspect variables in makefiles?
> Have a look at a simple makefile debugger (written in make):
> http://newsletter.embedded.com/shared/printableArticle.jhtml?articleID=197003517
404.
You got me all
* 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 s
* 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 som
Hi David,
Do you wanna set some breakpoints and inspect variables in makefiles?
Have a look at a simple makefile debugger (written in make):
http://newsletter.embedded.com/shared/printableArticle.jhtml?articleID=197003517
Regards,
Robert
---
Robert Berger
Embedded Software Specialist
Reliable
* 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
* Rob Landley <[EMAIL PROTECTED]> schrieb:
> Current compilers have a "build at once" mode where they suck the whole
> project in and run the optimizer on it at once, resulting in noticeably
> smaller and faster output at the expense of needing buckets of memory to hold
> all the source code an
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 ... n
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 ... n
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 exa
On Fri, 2008-06-13 at 13:15 +0200, Geert Uytterhoeven wrote:
> > For minimal file systems with a select handful of tools which can be
> > tested exhaustively, it's not so bad. But for any 'full-featured'
> > userspace, I think cross-compilation is completely insane.
>
> So, how does OpenWRT manage
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 *
On Thu, 12 Jun 2008, David Woodhouse wrote:
> On Thu, 2008-06-12 at 11:28 -0500, Bill Gatliff wrote:
> > > If you opt to cross-compile, having to deal with those
> > > sorts of things is the price you pay.
> >
> > If the build system derives from autoconf, then a hacked-up config.cache (or
> > equ
On Fre, 2008-06-13 at 08:43 +0200, Alexander Neundorf wrote:
> On Thursday 12 June 2008 17:50:31 you wrote:
> > On Thu, 2008-06-12 at 08:23 -0700, Tim Bird wrote:
> > > Rob Landley wrote:
> > > > However, having one or more full-time engineers devoted to debugging
> > > > cross-compile issues is qu
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 th
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 a buildsystem" POV: there will be user
On Friday 13 June 2008 10:38:36 you wrote:
> On Fre, 2008-06-13 at 08:43 +0200, Alexander Neundorf wrote:
...
> > 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
>
On Thu, 2008-06-12 at 19:25 -0500, Rob Landley wrote:
> Make doesn't scale.
Make scales just fine. The only real problem with make is that it's a
complete pain to debug.
--
dwmw2
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to [EMAIL PROT
On Friday 13 June 2008 02:25:34 you wrote:
> On Thursday 12 June 2008 11:12:13 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 wo
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
On Thursday 12 June 2008 17:50:31 you wrote:
> On Thu, 2008-06-12 at 08:23 -0700, Tim Bird wrote:
> > Rob Landley wrote:
> > > However, having one or more full-time engineers devoted to debugging
> > > cross-compile issues is quite a high price to pay too. Moore's law
> > > really doesn't help tha
>
> Um, actually Eric Raymond and I have had long talks about this, and if we're
> ever in the same state for more than 3 days we may finally get to do a
> serious research project about the successors to ./configure and make.
Tom has started a nice project which he named: quagmire.
See: http:/
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, and apparently the resulting make stuff was 1/17th the size
> of the original.
probably because scons has ~1/17th the functionality of autotools.
se
On Thu, 12 Jun 2008, Rob Landley wrote:
> He recently converted Battle for Wesnoth to use something called
> "scons" as its build system, and apparently the resulting make stuff
> was 1/17th the size of the original. You'd have to ask him for
> details, though...
scons is definitely wicked cool.
On Thursday 12 June 2008 11:23:19 Tim Bird wrote:
> David Woodhouse wrote:
> > I don't think that's true, unfortunately. Autoconf makes it _easy_ to do
> > the wrong thing, and people will often introduce new problems.
>
> If autoconf is the problem (and I think it is), then that's what
> should be
Rob Landley wrote:
> I just did a "make distclean" on a qemu tree I had lying around. On my 1.7
> ghz 64 bit laptop, it took 9.2 seconds to figure out it had nothing to do,
> just because it had to recurse into so many subdirectories to do it.
Which is precisely why recursive makes are conside
On Thursday 12 June 2008 11:12:13 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 w
On Thu, Jun 12, 2008 at 2:29 PM, Josh Boyer wrote:
> On Thu, Jun 12, 2008 at 12:05 PM, Mike Frysinger wrote:
>> On Thu, Jun 12, 2008 at 11:50 AM, David Woodhouse wrote:
>>> On Thu, 2008-06-12 at 08:23 -0700, Tim Bird wrote:
Rob Landley wrote:
> However, having one or more full-time engine
In message <[EMAIL PROTECTED]> you wrote:
>
> > Since perl was mentioned, it also makes a good example. Embedded distros
> > have been cross-compiling perl for pretty much the last decade, yet even
>
> Now I'm curious: where can I find a patch ?
See for example:
http://git.denx.de/?p=eldk/bui
Enrico Weigelt wrote:
> * Bill Gatliff <[EMAIL PROTECTED]> schrieb:
>
>> If the build system derives from autoconf, then a hacked-up
>> config.cache (or equivalent command-line args) often solves
>> problems for me.
>
> Only if you're working on *one specific* target for a long time.
> I, for
On Thu, Jun 12, 2008 at 12:38:42PM -0400, Mike Frysinger wrote:
>On Thu, Jun 12, 2008 at 12:31 PM, Paul Mundt wrote:
>> On Thu, Jun 12, 2008 at 11:28:10AM -0500, Bill Gatliff wrote:
>>> That's how emdebian is doing a bunch of their stuff, and I have to admit
>>> that it
>>> works pretty darned we
* Bill Gatliff <[EMAIL PROTECTED]> schrieb:
> If the build system derives from autoconf, then a hacked-up
> config.cache (or equivalent command-line args) often solves
> problems for me.
Only if you're working on *one specific* target for a long time.
I, for example, have to support lots of di
* Tim Bird <[EMAIL PROTECTED]> schrieb:
> If autoconf is the problem (and I think it is), then that's what
> should be fixed (see my original post).
ACK. One of the first things I did was replacing libtool and
kicked off broken-by-design macros like AC_TRY_RUN. This solved
at >80% of the proble
* Paul Mundt <[EMAIL PROTECTED]> schrieb:
> The other issue is that people that are working in this space tend to do
> very little beyond solving their immediate troubles.
Sad but true :(
> Since perl was mentioned, it also makes a good example. Embedded distros
> have been cross-compiling per
On Thu, Jun 12, 2008 at 12:05 PM, Mike Frysinger <[EMAIL PROTECTED]> wrote:
> On Thu, Jun 12, 2008 at 11:50 AM, David Woodhouse wrote:
>> On Thu, 2008-06-12 at 08:23 -0700, Tim Bird wrote:
>>> Rob Landley wrote:
>>> > However, having one or more full-time engineers devoted to debugging
>>> > cross-
On Thu, Jun 12, 2008 at 12:14:32PM -0500, 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
On Thu, Jun 12, 2008 at 1:14 PM, 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
>>
Adrian Bunk wrote:
> There's also the middle way taken by e.g. Scratchbox of using
> cross-compilers and other tools from the machine the compilation
> is done on, but emulating a native build for the software being
> compiled.
I suppose. But I've never gotten Scratchbox to work for me, at all.
David Woodhouse wrote:
> Yeah, I was building Red Hat Linux packages for sh3 many years ago,
> using tricks like that. But there was always _something_ else going
> wrong, however much you hacked around it. And a lot of it would only
> turn up at runtime, not build time. I would never consider ship
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
> itself. Autoconf/libtool damage is an entirely different p
On Thu, Jun 12, 2008 at 05:37:35PM +0100, David Woodhouse wrote:
> On Thu, 2008-06-12 at 11:28 -0500, Bill Gatliff wrote:
> > Guys:
> >
> > > If you opt to cross-compile, having to deal with those
> > > sorts of things is the price you pay.
> >
> >
> > If the build system derives from autoconf,
On Thu, 2008-06-12 at 11:28 -0500, Bill Gatliff wrote:
> Guys:
>
> > If you opt to cross-compile, having to deal with those
> > sorts of things is the price you pay.
>
>
> If the build system derives from autoconf, then a hacked-up config.cache (or
> equivalent command-line args) often solves pr
On Thu, Jun 12, 2008 at 12:31 PM, Paul Mundt wrote:
> On Thu, Jun 12, 2008 at 11:28:10AM -0500, Bill Gatliff wrote:
>> > If you opt to cross-compile, having to deal with those
>> > sorts of things is the price you pay.
>>
>>
>> If the build system derives from autoconf, then a hacked-up config.cach
On Thu, Jun 12, 2008 at 11:28:10AM -0500, Bill Gatliff wrote:
> Guys:
>
> > If you opt to cross-compile, having to deal with those
> > sorts of things is the price you pay.
>
>
> If the build system derives from autoconf, then a hacked-up config.cache (or
> equivalent command-line args) often so
Guys:
> If you opt to cross-compile, having to deal with those
> sorts of things is the price you pay.
If the build system derives from autoconf, then a hacked-up config.cache (or
equivalent command-line args) often solves problems for me. Just give the cache
the answers that it would otherwise
David Woodhouse wrote:
>>... fixing
>> them in the upstream packages (or in the autoconf system itself).
>>
>> Once someone fixes the cross-compilation issues for a package, they usually
>> stay fixed, if the fixes are mainlined.
>
> I don't think that's true, unfortunately. Autoconf makes it _eas
On Thu, Jun 12, 2008 at 12:08 PM, David Woodhouse wrote:
> On Thu, 2008-06-12 at 12:05 -0400, Mike Frysinger wrote:
>> people cant even write proper *native* makefiles. mtd-utils for
>> example ;).
>
> Criticism in 'diff -u' form preferred :)
i sent via `git-send-email` yesterday to the mtd lists
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* makefiles. mtd-utils for
> example ;).
meooow
On Thu, Jun 12, 2008 at 04:50:31PM +0100, David Woodhouse wrote:
> On Thu, 2008-06-12 at 08:23 -0700, Tim Bird wrote:
> > Rob Landley wrote:
> > > However, having one or more full-time engineers devoted to debugging
> > > cross-compile issues is quite a high price to pay too. Moore's law
> > > r
On Thu, 2008-06-12 at 12:05 -0400, Mike Frysinger wrote:
> people cant even write proper *native* makefiles. mtd-utils for
> example ;).
Criticism in 'diff -u' form preferred :)
--
dwmw2
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to [E
On Thu, Jun 12, 2008 at 11:50 AM, David Woodhouse wrote:
> On Thu, 2008-06-12 at 08:23 -0700, Tim Bird wrote:
>> Rob Landley wrote:
>> > However, having one or more full-time engineers devoted to debugging
>> > cross-compile issues is quite a high price to pay too. Moore's law really
>> > doesn't
On Thu, 2008-06-12 at 08:23 -0700, Tim Bird wrote:
> Rob Landley wrote:
> > However, having one or more full-time engineers devoted to debugging
> > cross-compile issues is quite a high price to pay too. Moore's law really
> > doesn't help that one.
> >
> > I'm not saying either solution is per
Rob Landley wrote:
> However, having one or more full-time engineers devoted to debugging
> cross-compile issues is quite a high price to pay too. Moore's law really
> doesn't help that one.
>
> I'm not saying either solution is perfect, I'm just saying the "build under
> emulation" approach i
97 matches
Mail list logo
