Re: Ada cross-compiler (Windows) to Android

[Ludovic Brenta <ludovic@ludovic-brenta.org>]

jrmarino writes on comp.lang.ada:
> On Jul 15, 12:06 pm, Ludovic Brenta <ludo...@ludovic-brenta.org>
> 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.