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 Mon, Mar 12, 2007 at 03:44:09PM +0100, Enrico Weigelt wrote: > > But once you have it in your patch stack, the packet works. > > Everything else is extra effort, without anybody really being > > interested in it. > > In short terms: yes. > > In long terms, maybe not (hope so ;o): often we have to fix every new > release, if our patches don't go into upstream. That suxx and eats up > resources. It eats up _your_ ressources, but customers tend to forget a packet once it works for them. > The big trick is to find an optimum between investing not more than > necessary, but enough for cooperating with those projects being worth > to. I already had to learn the lessons, that some projects simply > aren't intrested in my works, ie. mplayer or gtk, so I simply don't > care about them at all. I suppose you did it wrong then. > > 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 > > What do your *.make and *.in files do ? > For configuring / building the package ? Yep. .make files contain the building rules, .in files are Kconfig files for PTXdist's 'make menuconfig' system. > > In the future it will most probably be the canonical patch format > > used for Linux. > > How does this look like ? See Documentation/SubmittingPatches in your favourite Linux kernel. > > 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. > > hmm, I didn't have the time to read the docs yet. Maybe a reason why people don't care about your patches. Because _you_ don't have time to read docs, you expect _me_ to tell you how it works? Strange attitude. > Perhaps you could give quick examples. At the end I need exactly one > patch per release, which has some normalized location. (my buildsystem > does not care about patches, it just applies one single patch) foobar-1.2.3/patches foobar-1.2.3/patches/series foobar-1.2.3/patches/blub.diff foobar-1.2.3/patches/gargelpu.diff cat foobar-1.2.3/patches/series gargelpu.diff blub.diff Change into foobar-1.2.3 and run 'quilt push -a' to apply all patches, in the order specified in series. I leave the exercise of finding out how quilt is used while working on a packet to you. > Well, at least the initial mail, opening bug, etc can be done > automatically. I've written a small tool, which can be used to open > bugs (currently on bugzilla, but other issuetrackers can be added > easily) via commandline. Then I'm not wondering why your patches are dropped. > Well, for my unitool (and it's libtool-alike-frontend), it works quite > good for me - at least much better than libtool. Thanks to the frontend > (an some minor patch in autoconf, which just puts a call to lt-unitool > into libtool.sh), it works as an drop-in-replacement. What do you mean - patch in autoconf. I have > 400 packages, built by their respective maintainers. Do they all have to be repackaged? > So what do you think about my new patch dir structure (I recently > posted) combined with your headers ? Could you put a prototype somewhere, for review? 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] |