Re: cross-compiling alternatives
Enrico == Enrico Weigelt [EMAIL PROTECTED] writes: Hi, Enrico * Bernd Petrovitsch [EMAIL PROTECTED] schrieb: Recent pkg-config supports sysroot. FC-6 has only 0.21. Notice that sysroot is broken in 0.23 (it removes everything else than -I / -L words). Patches have been posted to the pkgconfig list several times. So you simply build your .pc files as usual (w/o sysroot prefix) and set the sysroot prefix via env on the pkg-config call. From a quick glance over the man page of 0.23, yes. Enrico Yep, it doesn't take $SYSROOT (as my original patch did), but with Enrico some prefix ... PKG_CONFIG_SYSROOT_DIR -- Bye, Peter Korsgaard -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
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 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 the value of these variables, this can be done either via a GUI (curses based or with cmake 2.6 also a graphical one), or via the command line: $ cmake -Dname_of_variable=new_value ...more options There is no simple automatic mapping from the variables to enabling features. Anyway, it is on the TODO for cmake to add some kind of support for project-configurable command line options, so that configure-compatible options could be provided. Lots of packages need special tools or other software installed to build them; this is no different. autotools need only a shell and make Yes, and requiring a shell is a lot, in the case you want to port also to Windows. Alex -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
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 imports libs [...]), so the buildtool (and user's config) can cope with it all. This was also the plan for cmake when it was started. But it turned out that this is not enough, and for more complex projects some programming logic is required. So cmake turned from quite declarative to quite imperative over time. So while declarative sounds nice, in practice it just isn't powerful enough. Alex -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
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 approach of tweaking command lines in the middle - it's an Pandorra's Box. I've already spent too much time on it and decided to completely drop it. Instead I prefer *clean* lines. Unitool provides commands on an higher level than, gcc+co do. These commands are on an higher functional level, hiding the individual platform's details. Also including things like importing .la-libs, sysroot, etc. Lt-unitool is a wrapper which parses the libtool commands and calls Unitool to do the actual work. Seriously, why is a wrapper for the compiler/linker required AT ALL if the calls to these tools are made from _generated_ files ? The generated files should just contain the appropriate calls for the respective commands. This layer of abstraction is unnecessary and IMO just adds confusion. (modifying libtool so that it calls unitool even seems to add yet another layer which can potentially break or bitrot etc.) Alex -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cross-compiling alternatives
On Fre, 2008-06-13 at 20:51 +0200, 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 'configure make make install' plus the usuall --enable-foo / --disable-foo / --with-bla=blub semantics is simply *the* standard way of configuring stuff for unix systems. You don't need fancy tools, you get cross compiling almost for free and unix people simply know how to use it. As long as people avoid AC_TRY_RUN() and similar and allow the configurator to tell `configure.sh` facts for the unavoidable cases about the target (and there were some apps - and I forgot the names - out there where this wasn't easily possible with editing the generated configure.sh. Yes, that's not fault of autotools as such but autotools make it IMHO far too easy to write that sort without generating lots of warnings[0]). All the cool kids out there who think they know everything better usually start with I hate autotools, then invent something which That has IMHO 2 main reasons: - For lost of apps, a Makefile and some coding discipline is more than enough to support Linux/*BSD/MacOS-X even on different hardware. And there are always cases where you need OS-specific code anyways (e.g. manipulating routes). Yes, that may need much more coding discipline than the average programmer is used to. - Converting $PROJECT to autotools is not easy. One has to learn and understand how the tools work[1] and what should be done in which way. And AFAIU (which is not much for autotools) one has to adapt the source anyways here and there (so it is not really a drop-in replacement). And if people consider using autotools, it is probably quite large and complex Add that to negative experiences with other autotools packages and I can understand the above sentence. solves 0.1% of the problems (including their very special problem) and tell the rest of the world that their shiny new tools is *s cl*. Bernd [0]: Yes, this is free software and I could send patches etc. to fix that. But that price is IMHO higher than just not using autotools for new stuff. [1]: And I didn't find a site yet with an easy understandable description for seasoned programmers with cross-compile and multi-hardware experience. -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cross-compiling alternatives
On Sam, 2008-06-14 at 01:07 +0100, Jamie Lokier wrote: [...] You said about too many user-selectable options. Many large packages These are IME not a problem if they have somewhat sensible defaults. _check_ for many installed libraries. Get them wrong, and you have the same problems of untested combinations. As long as I can specify that libfoo support must be compiled in (and thus libfoo must be present) and the tools throw an error if it doesn't find it, I have no problem. Otherwise all package builders have a serious problem. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cross-compiling alternatives
On Monday 16 June 2008 10:28:30 Bernd Petrovitsch wrote: On Mon, 2008-06-16 at 10:02 +0200, Alexander Neundorf wrote: [...] Seriously, why is a wrapper for the compiler/linker required AT ALL if the calls to these tools are made from _generated_ files ? AFAIU the motivation of libtool to provide OS-independent (and toolchain independent?) means to compile and link (etc.). The generated files should just contain the appropriate calls for the respective commands. But these calls are - e.g. for shared libraries - not identical. The Gnu toolchain is not everything. Yes, that's what I mean. The commands for calling the tools are generated. They should be generated appropriately for the respective toolchains (i.e. the generator must know how to call the different toolchains). No libtool/unitool/other wrappers required. Alex -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
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 those devices. (Think: inotify). It really should be in users/packagers control to explicitly enable features. But then there's a problem with 100 or more --enable-foo command line options. The user's script will _calls_ ./configure will bitrot... there's no way you'll be typing it on the command line. A big package can easily depend on that many local features. Nevertheless, the existence of some file or device says nothing about whether it will be usable (or *should* be used) at runtime. I've seen packages silently enabling some feature and then failing at runtime since the previously detected device is missing later. What a nightamare for packagers. I agree, assume they're all there is not sane. Another point are broken syscalls. Well, you *have* check at runtime to be sure, or perhaps choose to ignore it and expect a sane system. That said, to use rsync as an example. It uses the utimes() system call when available, and utime() otherwise, because the former is better. On current GNU/Linux it will use utimes(). Recently someone tried to run it on an old kernel, and it failed. If it tried utimes() first then fell back to utime(), it was fine, and rsync has a patch to do that now. 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? -- Jamie -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
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 -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cross-compiling alternatives
Bernd Petrovitsch wrote: _check_ for many installed libraries. Get them wrong, and you have the same problems of untested combinations. As long as I can specify that libfoo support must be compiled in (and thus libfoo must be present) and the tools throw an error if it doesn't find it, I have no problem. Otherwise all package builders have a serious problem. They do have problems, when you want to repeatably build and deploy, if the build environment isn't very similar each time. Typically the way you specify that libfoo support must be compiled in is --with-libfoo=/path/to/libfoo. That way lies bitrot between your build script which calls ./configure (since you won't by typing it manually with 20+ options like that each time you rebuild), and the changing version of an upstream package you configure. To prevent it trying to compile in libs you don't want, you also need --without-libfoo. Using Kerberos as an example, which I remember when building CVS ages ago: If you don't _prevent_ it using libraries you don't want, you get different binariesn depending on whether a Kerberos library was installed on the build system at build time. You might then send a built program to another system, and find it won't run at all, or has unwanted behaviour. Do you really see package building scripts with 20 --with-libfoo= and --without-libfoo= options in them for every library? Sometimes. But more often, not: instead, they more often have build-time installed prerequisites. -- Jamie -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
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 user-selectable options. Only works if you have the autoconf-menu tools already installed. ./configure --ask Invokes command line configuration questions / wizard for user-selectable options. ./configure --ask --from-config=OLDCONFIG Uses existing settings from a previous configuration. ./configure Without --menu or --ask, invokes traditional Autoconf automatic detection of capabilities. You said about too many user-selectable options. Many large packages _check_ for many installed libraries. Get them wrong, and you have the same problems of untested combinations. It even gets worse when they silently enable certain features on presence/absence of some lib. That's btw one of the reasons why sysroot is an primary constraint for me, even when building for the platform+arch. That's a basic design feature of Autoconf. And it really is very good most of the time - much better than config scripts which ask a lot of questions (Perl). Have you felt uncomfortable shipping a package that does use Autoconf, Automake and Libtool, knowing that the scripts generated by those tools are huge compared with the entire source of your package? Yeah, that's one of those things in autotools I never understood: why isn't there just one function for each type of check/action, which is just called with the right params ? It's because it's written in very portable Bourne shell, which does not support shell functions. (This is why I toy with the idea of writing a very portable C program, similar to a simplified shell, specially designed for Autoconf, with functions...) It could simulate functions portably by creating lots of little scripts at the start, and then calling them later on. That would shrink ./configure a lot. But it's a big change; somebody's got to do it, test it, look after it, and so on. Libtool similarly does not have to be huge, but it would be a lot of work to shrink it without breaking anything. It's hard enough to change it at all without breaking anything on some system, somewhere. -- Jamie -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cross-compiling alternatives
On Mon, 2008-06-16 at 12:17 +0100, Jamie Lokier wrote: Bernd Petrovitsch wrote: _check_ for many installed libraries. Get them wrong, and you have the same problems of untested combinations. As long as I can specify that libfoo support must be compiled in (and thus libfoo must be present) and the tools throw an error if it doesn't find it, I have no problem. Otherwise all package builders have a serious problem. They do have problems, when you want to repeatably build and deploy, if the build environment isn't very similar each time. Sometimes you have a different build environments - if only that you want to rebuild e.g. your .src.rpm on several versions of CentOS and Fedora. Typically the way you specify that libfoo support must be compiled in is --with-libfoo=/path/to/libfoo. That way lies bitrot between your build script which calls ./configure Cannot be really avoided IMHO. (since you won't by typing it manually with 20+ options like that each time you rebuild), and the changing version of an upstream package you configure. So be it. At least one sees errors/bugs immediately. To prevent it trying to compile in libs you don't want, you also need --without-libfoo. Using Kerberos as an example, which I remember when building CVS ages ago: If you don't _prevent_ it using libraries you don't want, you get different binariesn depending on whether a Kerberos library was installed on the build system at build time. You might then send a built program to another system, and find it won't run at all, or has unwanted behaviour. Do you really see package building scripts with 20 --with-libfoo= and --without-libfoo= options in them for every library? Sometimes. But For (in an ideal world 100%) repeatable builds - for a .rpm. .deb, some cross-compiled embedded device - one usually ends up with that explicit list (and IMHO it's the smaller PITA than to cope with strange bug reports because something was broken in the build weeks ago). Mainly because the dependency information is also present elsewehre (e.g. in the package). Or you really want control over the installed software. more often, not: instead, they more often have build-time installed prerequisites. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
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 you want it at all. Sometimes that's ok. But sometimes libc can't do that, because the point of a newer function is it addresses some inadequacy of an old function. If libc does a compatibility thing and uses old syscalls on old kernels, sometimes that introduces bugs. 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 now). The same applications are fine if pread returns ENOSYS and they know what they need to do with lseek and read. The same is true of the rsync example, with utimes and utime. It's wrong for libc to emulate utimes using utime on old kernels: they aren't the same. So the application does it instead: the application has a policy that it's fine with the different functionality when utimes returns ENOSYS. -- Jamie -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
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 now). Likewise pselect(). You're right -- it can't always be emulated. -- dwmw2 -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
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 likely interest... It's too big (as you rightly note) to simply sit down and do it by oneself in isolation. You are not seriously talking about writing yet another buildsystem ? With autotools, cmake, scons, ant, (b)jam, bitbake, makeng, etc. there should be enough available. Alex -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
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 ahead is to brainstorm and find ideas and likely interest... It's too big (as you rightly note) to simply sit down and do it by oneself in isolation. You are not seriously talking about writing yet another buildsystem? With autotools, cmake, scons, ant, (b)jam, bitbake, makeng, etc. there should be enough available. 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. -- Jamie -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cross-compiling alternatives
* Peter Korsgaard [EMAIL PROTECTED] schrieb: Hi, Notice that sysroot is broken in 0.23 (it removes everything else than -I / -L words). Patches have been posted to the pkgconfig list several times. ugh, why didn't they just apply my patch which only appends $sysroot to the pathes ? grmpf ... well, i'll stick w/ my 5-lines wrapper script ;-o Enrico Yep, it doesn't take $SYSROOT (as my original patch did), but with Enrico some prefix ... PKG_CONFIG_SYSROOT_DIR ack. cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ - -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
* 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 the value of these variables, this can be done either via a GUI (curses based or with cmake 2.6 also a graphical one), or via the command line: $ cmake -Dname_of_variable=new_value ...more options Are these variables strictly specified or is all left to individual author's decision ? autotools need only a shell and make Yes, and requiring a shell is a lot, in the case you want to port also to Windows. hmm, why not just expecting an sane shell on the building system ? (as you already have to expect a sane compiler) cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ - -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
* 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 imports libs [...]), so the buildtool (and user's config) can cope with it all. This was also the plan for cmake when it was started. But it turned out that this is not enough, and for more complex projects some programming logic is required. So cmake turned from quite declarative to quite imperative over time. And so you just open the Pandorra's Box again ;-o As soon as you try to build some one-fits-all-solution, you'll sooner or later run into similar problems as autoconf has. 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 cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ - -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
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 generated by autotools one is tempted to just ship a small, clean sh, written in C89 with autotools, use that and drop the workarounds. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
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 become part of Autotools - especially compatibility - is part of the goal. If you look at the sh scripts generated by autotools one is tempted to just ship a small, clean sh, written in C89 with autotools, use that and drop the workarounds. Exactly! Use an early, small Autoconf script written in very portable shell (as now) to detect the small set of features needed for this clean sh, and a host compiler. Then build it, then continue in clean sh. But if you're doing that, why use sh? It could be a subset of sh with extensions especially for this job - or something else entirely - to make Autoconf scripts cleaner, smaller, faster than they are now. Or even a tokenised sh, so Autoconf tests run directly on it but are compact. Possibly even _more_ portable (no need to depend on quirks of some utilities; configure scripts more checkable for common errors). And easier to configure things on environments with no shell (i.e. Windows). It adds an extra requirement for a host C compiler, but that's probably reasonable these days. This conversation ought to be heading over to the autotools lists... if anyone wants to take it up there. All public ramblings about how autoconf might be improved don't bring anything if you do not implement your ideas yourself and show that your implementation is better than the status quo. After all, open source development is not driven by people producing hot air but by people writing code... -- Jamie cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
