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 Wed, Mar 14, 2007 at 12:33:57PM +0100, Enrico Weigelt wrote: > > I suppose you did it wrong then. > > Subjective. Well, upstream had the same oppinion, so there are at least two subjects in this universe who think you did it wrong :) > Ah. At my site, those things are done in Briegel's (my buildsystem) > port config, which is out of OSS-QM's scope. IMHO, it's important to > keep things separated. Build systems have their own reasons to structure things. That's why I said create a "push buildsystem-patches into your project" path. > > See Documentation/SubmittingPatches in your favourite Linux kernel. > > hmm, looks quite nice, but since our patchfiles are not mails, we > should slightly differ, ie. Submitted-By" is IMHO better than "From". > I also suggest writing all comments in the header form. It's all about standards. Our patch files _are_ mails, if you 'quilt mail' a complete series to upstream. And you can talk about names, but the document is mandatory for 10k of Linux developers, so you'll probably have a hard life to argument against it. > > 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 > > The dir structure doesn't seem to be normalized. I don't know what you mean with "normalized" and I don't want to, but it is the way patches are handled in one of the biggest OSS communities out there. If foobar-1.2.3 extracts into foobar-1.2.3, it is so and not different. > > cat foobar-1.2.3/patches/series > > gargelpu.diff > > blub.diff > > Okay, quite equivanet to my patch list format (but 'm leaving off ".diff"). You can tell it whatever you like, as long as the entry in series is consistent to the patch name. > > > 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? > > Autoconf has to be re-run, so all it's autogenerated stuff will be > regenerated. Which is a showstopper. Users are never intended to have the autotools available, and nobody will repackage > 400 packets because of your idea. > > > 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? > > * CVSROOT=:pserver:anonymous@patch.metux.de:/home/cvs/repositories/oss-qm > * cvspass=anonymous > * module=oss-qm-patches Revision control system is a good idea, but could you please use svn instead of CVS? We don't want to go back to the mesozoikum :-) 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] |