From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,d1e954ab22509c0a X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,UTF8 Path: g2news1.google.com!news1.google.com!goblin1!goblin.stu.neva.ru!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: Ludovic Brenta Newsgroups: comp.lang.ada Subject: Re: Ada cross-compiler (Windows) to Android Date: Fri, 15 Jul 2011 22:14:24 +0200 Organization: A noiseless patient Spider Message-ID: <87r55r9u8v.fsf@ludovic-brenta.org> References: <12f3f5b7-5289-45c4-a346-7dc6ee2f274b@glegroupsg2000goo.googlegroups.com> <01b8c553-42e5-4ddc-877e-ef8f85361ac1@s17g2000yqs.googlegroups.com> <09b8124a-a200-407f-9e5f-4877d50088f1@r18g2000vbs.googlegroups.com> <2f757ea6-a681-463a-ab0e-dd29ae089276@u26g2000vby.googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: mx04.eternal-september.org; posting-host="hy06GHLf0zspoybG6C4+LA"; logging-data="12075"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19tVJ8nxaICI1J0uq/ptGq/" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) Cancel-Lock: sha1:L5RI/sYrkuptKMRNsD3r1jMogPM= sha1:6Vg8dk9eeszwXcY7Xm2peTRRa3A= Xref: g2news1.google.com comp.lang.ada:20209 Date: 2011-07-15T22:14:24+02:00 List-Id: jrmarino writes on comp.lang.ada: > On Jul 15, 12:06 pm, Ludovic Brenta > wrote: >> >> Could you explain how your repository is organized?  I would think >> you'd cloned the upstream git repository[1] and created a branch of >> your own where you maintain a stack of patches using quilt[2] or >> StGit[3]?  This technique allows you to make your patches available to >> anyone who wants them, even before you submit them to the FSF.  (The >> Debian patches are similarly maintained in a monotone repository, >> using quilt.) >> >> [1]http://gcc.gnu.org/git/ >> [2]http://savannah.nongnu.org/projects/quilt >> [3]http://git.or.cz/course/stgit.html >> >> -- >> Ludovic Brenta. >> The enabler generates a wide-spectrum, agile, bottom line, while >> siloed tactics enable the enablers. > > Sure, Ludovic. > I need to first make a distinction between gcc 4.6 series and 4.7 > series. > For the 4.6 series, I basically dumped gcc/ada (and subdirs) and the > two Ada testsuites along with some key files (e.g. config.gcc), > maintaining the same hierarchy. When it's time to build a tarball, I > overlay these files on top of a stock gcc. (for c++ testsuite and a > few key files, I also apply a set of patches). > > That technique basically forced me to use "meld" a lot and manually > maintain a list of files that differs. It is painful to do. > > So solve that, and to prepare proper patches for import into gcc, I > created a new branch for gcc 4.7 that only contains patches. To > produce 4.7 tarball, I just apply the patches to a copy of the stock > gcc. That way I can just send the patch to gcc and remove it from the > repository after it gets accepted. That was the plan anyway, and the > idea is that over time the number of patches would decrease to a very > low number. > > I took a quick glance at that quilt site which I had never heard of > before, but it wasn't immediately obvious to me how it is supposed to > work. Maybe the man page[4] is more explicit. Basically, quilt is a tool to help with what you're doing, i.e. maintain a stack of patches on top of a GCC pristine release. You can "push" a patch (i.e. apply it), "pop" a patch (un-apply it), "refresh" a patch (i.e. recompute the diff), and reorder patches. Quilt keeps track of the name and order of your patches, and of which patch is currently the topmost applied to the pristine sources. [4] http://linux.die.net/man/1/quilt When a new version of GCC is released, you use quilt to re-apply all your patches to it, in order. When things break, you redo your changes manually then refresh your patches. StGit is a similar tool specifically designed for use with git (i.e. where the pristine sources are in git). I suggest you consider using either tool to manage your patches and place only your patches in your repository. -- Ludovic Brenta. The steering committee empowers our organic contents.