Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
* 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 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 ? Authors decision. Then you've got the same problem as w/ autoconf's config.status: You have to tweak it for each individual package separately :( My destiny is to have strictly standardized variables for all the common things, so you can use an global per-target configuration for *all* packages ever coming. That's what Unitool's system properties db is for. hmm, why not just expecting an sane shell on the building system ? (as you already have to expect a sane compiler) Well, we could go so far to expect a sane operating system, but you can't change it, there are insane people in the world ;-) Many, many things can be done within in the toolchain, eg. fixes for broken libc's. For example, I've seen packages adding several missing functions for certain platforms - this should be the job of the toolchain. 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)...)
* 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 at your descriptive paragidm. Yes, but mine is much simpler and syntactically stable. With autotools there are uncountable things you can do wrong, without even noticing - it needs *very* much care. In TreeBuild there's almost no room for those mistakes. A simple typo can lead autoconf to unpredictable behaviour - TreeBuild spits out an parse error. So for these cases (which already make up a very large number of total packages in the world), maintaining buildfiles becomes a lot easier ;-P And despite all nasty details of autoconf/automake/libtool they also have advantages: - they are quite powerful when you know how to handle them The point is: you *must* know autotools very well, otherwise you soon run into pitfalls. - they allow to build your software on non-Linux systems TreeBuild does that too, as soon as someone wrote a proper config for another platform. The design is platform agnostic, just lacking ports to other platforms, due lack of (my) time. - they are the de-facto standard in the open source world, and everyone building open source software knows them I don't think that this is a good argument. M$-Word is also an de facto standard ;-P And the last point is a very important one: For me as someone who is often compiling software your plan of creating yet another build tool I have to handle does not sound like a good idea. Yes, but that's not a problem of TreeBuild, but the total count of different build systems around the world. That's why a new buildsystem should be an really good solution for an reasonable class of problems and should be easy to learn. IMHO, TreeBuild does this - for simple structed packages. (which make up about 99% of my own ones). Of course, TreeBuild still in an early development stage. So I don't claim it's really usable for everyone - for now it's more an academic issue. 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 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 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 ? Authors decision. Then you've got the same problem as w/ autoconf's config.status: You have to tweak it for each individual package separately :( Well, these are all more or less scripting languages, so people can create whichever variables they like, no way to enforce something. Still one can suggest standards which should be followed. 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 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 (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 (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 (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 (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
Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
* 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 switches is the job of an automated distro builder tool, including things like dependency tracking. Actually, I'm really too lazy for doing those stuff by hand ;-P But you're right, some packages have too many optional features, which better should be their own packages, and there's sometimes much code out there which should be reused ... Some other packages _should_ have more options, but don't because it's too unwieldy to make them highly configurable with Autoconf. Adding new feature switches w/ autoconf is almost trivial (well, not completely ;-o) 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), or with a config file. Yes, that would be fine. But for me the primary constraint is that all switches/options can be specified by command line - otherwise I'd need extra complexity for each package in my distbuilder tool. Perhaps it might even be possible to write a very small, portable, specialised alternative to Make which is small enough to ship with packages that use it? No, I really wouldn't advise this. Make tools are, IMHO, part of the toolchain (in a wider sense). Once point is avoiding code duplication, but the really important one is: a central point of adaption/configuration. That's eg. why I like pkg-config so much: if I need some tweaking, I just pass my own command (or a wrapper). If each package does it's library lookup completely by itself, I also need to touch each single package in case I need some tweaks. I had exactly that trouble w/ lots of packages, before I ported them to pkg-config. 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)...)
* 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/ autoconf (this is not autoconf as primary directive ;-P) ... I guess we've got the same one in mind ;-) 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 ;-) Most packages need lots of additional libraries installed - and the development versions of those libraries, for that matter. Too often the right development version - not too recent, not too old. With the wrong versions, there are surprises. But that's not the problem of autoconf or any other buildsystem, just bad engineering (often on both sides). 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. 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 ? 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 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 decide about the winner. (since Eric is good at arguing I guess it will be scons). and apparently the resulting make stuff was 1/17th the size of the original. probably because scons has ~1/17th the functionality of autotools. seriously, it's terrible. I saw the presentation about scons by the main scons developer at FOSDEM this year and it felt more like a library which you can use to create a buildsystem, not like a ready-to-use buildsystem itself. Alex -- TU-Kaiserslautern Lehrstuhl für Echtzeitsysteme Postfach 3049 D-67653 Kaiserslautern Germany Tel: +49 (0)631 205 3644 Fax: +49 (0)631 205 4199 -- 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 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 a buildsystem POV: there will be users who will need it. I think that epitomises what's wrong with autoconf. Sometimes, the best Actually I think autoconf itself is not that bad. What is bad is autotools, i.e. that you get a combination of several tools which have to work together, all huge shell scripts, all using different syntax, etc. thing to do is tell your users that they _don't_ need whatever it is they're asking you for. We agree that if possible, tests which run something should be avoided. But seriously, sometimes this is really very hard. I don't dare to say impossible, but I'm tempted. 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). 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 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* makefiles. mtd-utils for example ;). 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 of a makefile (or makefiles) done *right*. as in, properly recursive, supports cross-compiling without having to ^^ Ugh? remove your left nad, etc, etc. so ... would anyone like to recommend a software package or two somewhere whose makefile(s) is/are, ITHO, done well? that i/we could just point at and say, do it like that! anyone? anyone? bueller? The kernel, except that it's still recursive? With kind regards, Geert Uytterhoeven Software Architect Sony Techsoft Centre The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium Phone:+32 (0)2 700 8453 Fax: +32 (0)2 700 8622 E-mail: [EMAIL PROTECTED] Internet: http://www.sony-europe.com/ Sony Technology and Software Centre Europe A division of Sony Service Centre (Europe) N.V. Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium VAT BE 0413.825.160 · RPR Brussels Fortis 293-0376800-10 GEBA-BE-BB
Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
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 of a makefile (or makefiles) done *right*. as in, properly recursive, supports cross-compiling without having to remove your left nad, etc, etc. ... Please read the essay Recursive Make Considered Harmful (http://miller.emu.id.au/pmiller/books/rmch/). Bart. -- 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 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 subscribed since i dont have a direct interest in mtd development ... It is. I just missed it. I'll look closer today. Thanks. josh -- 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 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 subscribed since i dont have a direct interest in mtd development ... It is. I just missed it. I'll look closer today. Thanks. josh -- 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: 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 makefiles ;-P Basically only the last one is problematic (but IMO still less problematic than running a virtual system on the host just to build something). Yes, and that should be completely prohibited. How does cmake support that for cross compiling ? If it detects a try_run() (which is the command for building a test executable and then running it) in cross compiling mode (i.e. when it was told what the target platform is instead of just assuming it's the same as the build host), then it -issues a warning -stores the created executable in a place so the developer can find it -running some existing executable and checking its output -creates a file where the developer can enter the results which running the executable on the target host would have brought (includes comments where that command was found, the arguments, etc.,). The developer can then run the test executable manually on the target and enter the results. This seems to be similar to the config.cache somebody mentioned for debian. Yes, introducing the problems as with autoconf. You'll have to maintain one cachefile per package - there is *NO* standard on it's variables. And exactly that's the key problem ! Therefore unitool has an generic platform database, where such generic platform parameters can be set. These fields have to be standardized, (adding new ones for some specific package is definitively the wrong way). So really the hard part is getting rid of running stuff to check the platform. Isnt that hard. In all these years I had no case where it couldn't be circumvented. 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: 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 you just built Some concerete examples where you really *need* that ? The last one is the problem for cross compiling. Example: detecting the size of ints Easy way: ... printf(%d\n, sizeof(long)); ... Why not directly using sizeof() in your code ? 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: 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 engineering from ground up. BTW: python is one of the packages didn't pass a single one of my QM constraints (hey, not completely corrent, IMHO, install prefix was passed ;-O) 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 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 solely using GNU make features -- no preprocessing is required. Last time I looked it had *at least* 0.1% of the autotools features supported :-) rsc -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hannoversche Str. 2, 31134 Hildesheim, Germany Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9 -- 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)...)
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 to show you the values of certain things. It is helpful, but not an interactive debugger. However, the guy who wrote that article did indeed write a full Makefile debugger. I took it for a spin, and found that it worked as advertised on a simple Makefile. I tried it on the kernel Makefile, but without success (but I didn't try very hard). YMMV. I put some of the resources and info I found at: http://elinux.org/Debugging_Makefiles The link from the package's README doesn't work, but here's a link I found to an article about the debugger: http://www.cmcrossroads.com/content/view/6479/120/ The links in the README worked fine for me. FWIW, the authors homepage is here: http://gmd.sf.net He's written a self-published book on GNU Make, it would seem. -- Tim = Tim Bird Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Corporation of America = -- 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 -- 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 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
itself. Autoconf/libtool damage is an entirely different problem :-)
At first glance, it seems like checkincludes.pl could be duplicated by
egrep | uniq | wc vs. egrep | wc. Not quite sure what checkversion.pl is
trying to do.
There's a difference between this is a development tool used while modifying
source code and this is needed to build.
There are situations where it's ok to have a dependency on X11/qt/gtk, such
as make xconfig. This is _not_ the same as adding such dependency to make
modules.
So far, none of the perl dependencies prevent you from building the kernel on
a system that didn't have perl (or didn't have the right version of perl).
So maybe we could _reduce_ dependency on perl, if there's any advantage to
gain by doing so. But the kernel build machinery isn't dependent on very
many other systems (just tcl, bash and gcc-core),
There's no tcl dependency in the build. (Yes, I actually know this.)
Part of my FWL work involves getting the system to rebuild itself under
itself. (The packages you need to make a minimal self-bootstrapping system
are gcc, binutils, make, bash, uClibc, linux, and busybox/toybox). I'm seven
commands away from doing this.
I know this because I made a horrible little wrapper (attached, it really is
sad) which touched a file with the name it was called as and then exec()ed
the actual executable out of another directory. Then I populated a directory
with symlinks to every executable in $PATH (for i in `echo $PATH |
sed 's/:/ /g'`;do for j in `ls $i`; do ln -s $i/$j $j; done; done), and
another directory of similar symlinks to my wrapper. I then ran my build
with that wrapper directory at the start of $PATH and let the wrapper
populate a directory with all the executables that actually got called during
the build. Then I filled up a directory with those executables, tried to run
the build, and figured out why it broke. (The above approach won't find
calls to /bin/bash and a few other things, but it's a good start.)
Most of the point of my ./host-tools.sh wrapper in the FWL build is to
populate a directory with the command line utilities mini-native will have in
it (specifically the busybox/toybox versions, not the ones in the host
system), and set $PATH equal to that directory and only that directory. This
way I know the system will build under itself because that's how it's
building in the first place.
Currently, I need to grab the following out of the host system:
for i in ar as nm cc gcc make ld bzip2 find install od sort diff wget
do
[ ! -f ${HOSTTOOLS}/$i ] (ln -s `which $i` ${HOSTTOOLS}/$i || dienow)
done
The first seven are the needed bits of the host toolchain (you'd think strip
would be in there, but it turns out those packages only ever use
$TARGET-strip). The last seven are the ones that are either missing or had
various bugs in the version of busybox I'm using that prevented the build
from working right.
Rob
--
One of my most productive days was throwing away 1000 lines of code.
- Ken Thompson.
#include stdio.h
#include string.h
#include stdlib.h
#include fcntl.h
char blah[65536];
#define ROOTPATH /home/landley/firmware/firmware
int main(int argc, char *argv[], char *env[])
{
char *p, *p2;
int i, fd;
p2 = strrchr(*argv, '/');
if (!p2) p2=*argv;
else p2++;
p=blah + sprintf(blah, %s ,p2);
for (i=1; iargc; i++) {
p += sprintf(p, \%s\ ,argv[i]);
}
p[-1]='\n';
// Log the command line
fd=open(ROOTPATH /loggy.txt,O_WRONLY|O_CREAT|O_APPEND,0777);
write(fd, blah, strlen(blah));
close(fd);
// Touch the file that got used.
sprintf(blah,ROOTPATH /used/%s, p2);
close(open(blah, O_WRONLY|O_CREAT, 0777));
// Hand off control to the real executable
sprintf(blah, ROOTPATH /handoff/%s, p2);
execve(blah, argv, env);
// Should never happen, means handoff dir is set up wrong.
dprintf(2,Didn't find %s\n, *argv);
exit(1);
}
Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
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 that signal handling in the mips version of perl is using the x86 signal numbers and they're not the same: priceless. The only simple solution so far (without diving into the implementation and searching for root causes) were AFAICS: - do not use libtool for linking (as the link line as such without libtool works as expected) Yes, libtool sucks, it's the wrong solution to the problem. (and CMake doesn't use it). Nothing on Linux really _uses_ libtool. It's supposed to act as a NOP wrapper around the linker on any Linux target. (It's there for things like Sparc and HPUX). The fact that libtool manages to do its nothing _wrong_ so often would be hilarious if it wasn't such a pain. Just uninstall libtool before trying to build for a Linux target, this should never cause any problems and will save you lots of headaches. 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). According to the LP64 standard which pretty much all modern Unixes adhere to (including both Linux and MacOS X) sizeof(int) is always 4. Guaranteed. The LP64 standard: http://www.unix.org/whitepapers/64bit.html The LP64 rationale: http://www.unix.org/version2/whatsnew/lp64_wp.html The insane legacy reasons windows doesn't do this, but in fact sizeof(int) will still be 4 there anyway: http://blogs.msdn.com/oldnewthing/archive/2005/01/31/363790.aspx Just FYI. :) But this was not the point. My point was: testing something by running an executable can be _a lot_ easier than testing the same without running something. I think building natively under qemu is the easy way, yes. :) 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 -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. -- 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 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, though. http://sourceforge.net/projects/bashdb/ Johannes -- 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)...)
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. 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. Some other packages _should_ have more options, but don't because it's too unwieldy to make them highly configurable with Autoconf. 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), or with a config file. The make / make install part is easy to retain even with other build systems, using a trivial Makefile which calls the other tools. Lots of packages need special tools or other software installed to build them; this is no different. Perhaps it might even be possible to write a very small, portable, specialised alternative to Make which is small enough to ship with packages that use it? -- 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 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 more difficult it becomes to test all the combinations. Some other packages _should_ have more options, but don't because it's too unwieldy to make them highly configurable with Autoconf. 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), or with a config file. That's exactly what ptxdist does: add a Kconfig frontend to the configurable switches. It does it for the user's convenience, although the currently implemented method is really developer-unfriendly (but we care about our users first). But it's of absolutely no use to whine about the fact that the world is such a curel place. *If* Kconfig had been there 20 years ago ... *if* 90% of the packages out there would have been Kconfig instead of autotools... We have to live with *reality*, and reality is that autotools solve real world problems, and they offer *one* standard user interface to package building. I can cross build almost all autotoolized packages in exactly the same way and people are used to it. All other build systems I've seen invented their very special way of doing things, leading to wheel-reinvention all over the place. The make / make install part is easy to retain even with other build systems, using a trivial Makefile which calls the other tools. 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. Lots of packages need special tools or other software installed to build them; this is no different. autotools need only a shell and make Perhaps it might even be possible to write a very small, portable, specialised alternative to Make which is small enough to ship with packages that use it? Why on earth would one want to reinvent make? rsc -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hannoversche Str. 2, 31134 Hildesheim, Germany Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9 -- 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)...)
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 more options you have, the more difficult it becomes to test all the combinations. Kernels, uclibc, busybox. All combinations can't be tested. But it's still _very_ useful to compile in only those parts wanted. Most packages have far fewer. But some have enough that the command line is unwieldy and Kconfig would fit. I'm thinking libcurl - one configure option for each protocol supported. iptables (userspace) would be a candidate, when you have to link statically and save space. Media players with lots of optional formats and drivers are another. (They also have considerable problems with their Autoconf in my experience). Generally, anything with lots of parts that different applications might not use, and space or library dependencies are an issue. Some other packages _should_ have more options, but don't because it's too unwieldy to make them highly configurable with Autoconf. 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), or with a config file. That's exactly what ptxdist does: add a Kconfig frontend to the configurable switches. It does it for the user's convenience, although the currently implemented method is really developer-unfriendly (but we care about our users first). I agree. (And it proved about not being able to test more combinations: last time I tried to build ptxdist, an up to date version (at the time), it failed in several places.) But it's of absolutely no use to whine about the fact that the world is such a curel place. *If* Kconfig had been there 20 years ago ... *if* 90% of the packages out there would have been Kconfig instead of autotools... We have to live with *reality*, and reality is that autotools solve real world problems, and they offer *one* standard user interface to package building. I can cross build almost all autotoolized packages in exactly the same way and people are used to it. All other build systems I've seen invented their very special way of doing things, leading to wheel-reinvention all over the place. I agree with you. There's no need to disagree, and who's whining? We're trying to think of realistic improvments. Reality is that Kconfig front end to autotools does work - as you've proved. It's a good idea. :-) The make / make install part is easy to retain even with other build systems, using a trivial Makefile which calls the other tools. 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. Me neither. Lots of packages need special tools or other software installed to build them; this is no different. autotools need only a shell and make No, that's true only for very simple packages. Most packages need lots of additional libraries installed - and the development versions of those libraries, for that matter. Too often the right development version - not too recent, not too old. With the wrong versions, there are surprises. 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. Quite a lot of packages require extra tools to build, beyond shell, make, GCC and Binutils. Perl, Python are common. Sure, autotools by themselves don't need much. But that's not interesting: Autotools are not used only by themselves. Perhaps it might even be possible to write a very small, portable, specialised alternative to Make which is small enough to ship with packages that use it? Why on earth would one want to reinvent make? 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? Have you _written_ Autoconf tests recently? Made any shell / shellutils non-portability mistakes in the tests? Have you _read_ a portable Makefile lately? Have you tried writing one for a complex package, confident that it's portable to different quirky makes, quirky shells and quirky tools, outside the parts which you might use Automake for? That's a rationale for the project which is rewriting Autotools in GNU Make, assuming that to be ubiquitous now, imho. (Not all interesting systems have a shell either.) If you're going to rewrite Autotools using GNU Make, why not ask if another tool would be better, perhaps a tool specially
Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
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 help that one. I'm not saying either solution is perfect, I'm just saying the build under emulation approach is a viable alternative that gets more attractive as time passes, both because of ongoing development on emulators and because of Moore's law on the hardware. I agree with much that you have said, Rob, and I understand the argument for getting the most gain from the least resources, but I have a philosophical problem with working around the cross-compilation problems instead of 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 _easy_ to do the wrong thing, and people will often introduce new problems. 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 ;). -mike -- 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: ... 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 _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 fixed (see my original post). At a minimum, it would be nice if it had more built-in detection and warning of techniques that were dangerous for cross-compilation. While I was writing the above, Paul Mundt wrote: You can either try to fix the packages in question, convince the package developers to rip out the parts that cause trouble for your environment, fix your own build environment to meet the needs of the packages, or whine about it on a mailing list. Empirically we already know which one of those options is going to win out. ;-) LOL. Well, at least Rob has put his money where his mouth is (so to speak) with Firmware Linux. The chance that I'll do anything but whine about autoconf is slim indeed... I'll shut up now! -- Tim = Tim Bird Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Corporation of America = -- 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)...)
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 have to get by running code on the target machine. That's how emdebian is doing a bunch of their stuff, and I have to admit that it works pretty darned well. It's also handy for configuration management, since the cache file itself is plaintext and therefore svn/git/bzr/cvs/...-friendly. b.g. -- Bill Gatliff [EMAIL PROTECTED] -- 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
