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
* 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)...)
* 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: [PATCH 0/1] Embedded Maintainer(s), [EMAIL PROTECTED] list
* Samuel Robb [EMAIL PROTECTED] schrieb: When you have a one- or two-line fix, and face Yet Another round of finding the right mailing list, identifying the right maintainers, figuring out the right way to submit a bug and a patch, and then have to spend the next 3 weeks explaining how no, you're not interested in being the PPC maintainer for libfoo... is it any wonder that developers (not to mention their management) eventually just gives up on the idea of giving back to the community? ACK. One possible solution would be to provide a clearing house for these sorts of changes, maybe under the auspices of CELF or a similar organization. Instead of submitting patches to individual projects, submit them to the clearing house, and let interested individuals either gather together and push related patches upstream in individual projects, or give project maintainers a place to go and find embedded systems patches related to their projects. See my last mail: that's exactly what the oss-qm project is for: http://oss-qm.metux.de/ With OSS-QM and related tools you often even don't need your own patching infrastructure - oss-qm provides complete patches against virtually any package/release. Perhaps a few words on the infrastructure: * single patches are collected per package, each vendor may get his own namespace/subdir, where he can feed in his patches. * the single patches are automatically pulled together based on listfiles - per package+release there is an simple text file which just lists the single patches to be pulled together. * each vendor may get it's own namespace for the listfiles. In other words: if you fear somebody else breaks your already tested/approved packages, just use your own (listfile) namespace. BTW: CSDB does a similar thing for retrieving source tarballs. Just query the DB, never ever care about individual URLs in you local build system. 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: 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 Compiler and loads of issues
* Jamie Lokier [EMAIL PROTECTED] schrieb: For some reason, that stopped a while ago, and you had to go to different places to get working basic tools. And often, the place to go wasn't clear. Different people advertised their ARM toolchain, m68k toolchain etc. and they were slightly different sets of patches on top of mainline tools. Central authorities you might believe in existed, but they were always a few patches behind what you actually needed. That's because many embedded build their toolchains completely on their own, instead of just using an generic toolkit like ct. Contrast with kernel.org: everyone knows where to get a good working Linux kernel for the mainstream architectures, and the quality work tends to be quite good at reaching mainline there nowadays. ACK. But you perhaps remember the discussions on LKML where some folks wanted to stop this and leave all the QM works to individual distros. I'm glad this plan was dropped. 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
