This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On Sat, Mar 10, 2007 at 03:22:22PM +0100, Enrico Weigelt wrote: > I don't think they would get their problems out of sight. Instead > they would all save much work and provide big help to the package > developers. The problem is that fixes have to real fixes, not ugly > hacks to get in. For example, always fixing the real sources, not > playing around in autogenerated files (ie. ./configure). Yes, sure, we do it the same way. But once you have it in your patch stack, the packet works. Everything else is extra effort, without anybody really being interested in it. > So, we're doing quite the same, we want quite the same, now let's > get our repositories compatible. > > Mine has an quite simple structure: one directory per package dito here (although we have a directory "generic" inside, which is historic and could be removed some day). > (names probably normalized -- see oss-qm wiki) You cannot enforce naming policies; we use the normal packet name for that, which is usually what you get if you extract a packet. There are activities on the way to restructure our packets to have something like memedit-1.2.3/ memedit-1.2.3/patches/ memedit-1.2.3/patches/memedit-1.2.3-fix-something.diff memedit-1.2.3/memedit.make memedit-1.2.3/memedit.in As I said before: I see no point in talking all similar projects out there into using the same format. If you want to push something, make yet another patch repository, plus automated scripts which make it easy for the maintainers of the projects to automatically convert and push their patches in. Regarding the patch format, we have our own header ontop of it, to specify things like the upstream status, source or the error etc. In the future it will most probably be the canonical patch format used for Linux. T2 has an interesting packet description & patch format as well... > there some patches.db file which lists patches per (normalized) > release, and the patches are sitting within the src subdir. The community tool for getting patches in order is quilt; so we use quilt like series files in our patch repositories. It also makes patch development easy: just link the patch dir into a breaking project and use quilt to maintain the patch. > Of course, evryone may have it's own tree(s). But all trees have the > same structure, we can operate with the same tools in them and these > tools provide easy techniques for finding changes/updates, etc. Seconded. > And we also have tools that automatically notify the package > maintainers. Forget it. Patch feeding is communication, and it needs _active_ work with upstream. > > For example, somebody who rants libtool would probably be sub optimal =8-) > > Heh, this clearly goes into my direction ;-o Dum titum .... > Yeah, I'm not very diplomatic, but I've got my reasons against libtool > - you probably know them. We agree that libtool has problems. But it is the same with libtool as with for example cmake: People come and want to do everything better what has been done by skilled developers for years. They make something new, and in the end it does the deficiencies 100% perfectly, but on the way 50% of the old functionality is lost. Cmake for example still cannot cross compile as far as I know, and it breaks the known-for-decades way of building packets with ./configure && make && make install, together with well established methods like --with-foobar=blub and --enable-baz. So IMHO the only solution is: fix libtool. > Grmpf, I'm talking about the organisation structure, management tools, > etc, not the actual patches. My trainee can of course build some scripts > for comparing trees, notifying about changes, cat'ing patches together ... Yes, sure. So for the moment I'd say that we are generally interested in such a project, taken that it is structured in a way that we may discuss a generic patch + documentation format and build automatisms to push patches from the build systems into a QM project. Let's do some more thinking about how to structure it correctly... Rene, what is your oppinion? Would you also be interested? It might also be a good idea to ask buildroot, open-embedded etc. And, of course, it would have to happen under a neutral organisation. I wouldn't also mind to let this thing be quality.pengutronix.de to get the marketing effect ;) but if we want to be it a success, it must be strictly vendor neutral. LTP could be a candidate, or the Linux Foundation. Has anybody contacts? Robert -- 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 -- For unsubscribe information see http://sourceware.org/lists.html#faq
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |