Hi Martin Thanks for your reply.
Martin Hejl schrieb: > Hi Erich, > ... > I'm not sure what exactly you're suggesting - do you mean we should > check in the whole /stuff/sourceforge/src/bering-uclibc/buildtool tree > (including source, build and staging) from a box that has build > everything available? If so, I don't understand what is "hierarchically > flat" about that Sorry, my wording is misleading, single tree would be the term, I believe. - but we'd surely burn a lot of disk-space on the SF > servers... We would indeed, but hardly more than we do right now. > Or do you suggest we'd check in the > /stuff/sourceforge/src/bering-uclibc/buildtool/source tree (with > everything unpacked)? That has been suggested in the past (or something > along those lines), since it would make it easier to see what changed > between releases. But I like the "upstream tarball + patches" approach, > since it makes it easier to remove a patch, once it's no longer needed. > Besides, that would not fix most of the problems people have (since most > of the time, they're due to incompabilities between the source being > compiled, and the toolchain on the host computer). We would need the toolchain along with the source. > >> Having read lately >> about trouble getting the buildenv set up convinces me that a flat CVS >> could lower maintenance effort. > Possibly - at the price of adding support issues in other places (if I > understand your suggestion correctly). Possibly, but I could not really fathom this > The problems we're having with buildtool (at least the latest ones) have > little to do with keeping the sources apart, and much more to do with > changes in the tool-chain (ubuntu ships a different gcc,libs,kernel > headers than RHEL than debian and so on). > But maybe I'm misunderstanding your suggestion - please clarify if you > think that might be the case. Mhhh.. maybe I am underestimating the issues with the toolchain. I was under the impression that most of the stuff is perl anyway, so at least partly portable. I _believe_ also, that a precompiled toolchain would work on most recent distributions, as we are distributing gcc and the bintools too. ...> We don't, as far as I can tell - apart from a few sources, like the > kernel and gcc (I agree that we should probably keep those in cvs as > well). In short, we already keep the sources of everything (minus kernel > and gcc) already. > >> I believe it would also be easier to >> handle comprehensive versioning as everything may depend on a certain >> version of the development environment. > Not so far (but it is a possibility this may happen) - so far, we try > our best to make sure that a checkout of the buildenv for a given > timestamp works with a checkout of everything else for a given timestamp > - so basically, that versioning is already in place. Yes, until now this is maintainable, as long as the toolchain version remains stable. I was a bit puzzled though that, for example, I would find kernel version information in the buildtool.mk files, but this may be just an example for source to be fixed. I am convinced though it is easier to keep a single tree in sync than multiple trees. > > Again, maybe I'm misunderstanding what you're suggesting - but if I'm > not, it would make life harder for the people who actually use the > buildenv to develop new packages regularly (since an update to cvs might > break something the next time they do "cvs update"), while it would > surely help those who just want an up to date buildenv quickly, to > compile something. Basically this is what I am suggesting. Just for my understanding, what do you think could break the individulal developers workspace in this case? CVS should protect against exactly these problems. > > There has been work on getting a vmware (or something similar) image > that provides a buildenv - would that help? I guess it's not finished > yet, as always, due to the lack of extra time available. I guess this is a good idea, although I am personally not that hooked on VMWare as it is another closed source environment. I believe even a simple compressed filesystem which can be mounted and chrooted into (as was available with Bering glibc) could be one possible, although primitive, solution. Another one could be a KNOPPIX image covering the actual release with tools and sources. > > There's even been work on setting up a self-contained uclibc-only vmware > image (would be cool for those troublesome sources that insist on > linking against the host libs, no matter what you do), but that has died > half way, due to lack of time. And basically, I don't think that's the > way to go, since we should work on fixing the sources, to make them be > able to handle a cross compile. Agreed, I ran into such issues in the eql_enslave stuff. I believe this is very difficult though, as we need to maintain patches against the uplink sources at all times and this is very time consuming. > > In short - a lot has been tried to make the process of getting a working > buildenv easier - but so far, it all died half way, before the point > where it could be given to the people who are having a hard time setting > up a build environment. And all that comes down to lack of manpower - if > there were a handful of people working on just that task, it would be > doable. But as long there's only a handful of developers on the whole > project, I don't see it happen (unless somebody who really wants that > fixed picks up the ball and does it). > > Just my thoughts - I'm not speaking for anybody but myself. It is great to know what is going on behind the curtains :-) Thanks for your time and information. Erich ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
