On 01/26/2011 11:40 AM, Eli Zaretskii wrote:
>> I have proposed in [2] a modification to the Emacs sources that will ensure
>> that
>>   - No c++defs.h is contained in the build.
>>   - A gnulib-local/modules/c++defs.orig file is contained in the tarball but
>>     not used in the build. According to Eli [3][4] the djtar program can
>>     deal with such a file automatically.
> 
> IIUC, the file gnulib-local/modules/c++defs.diff is a patch to be
> applied by gnulib-tool when it reads c++defs from the gnulib
> directory.  But what is the file gnulib-local/build-aux/cxxdefs.h for?

The counterpart of the c++defs.diff patch that provides the contents of
the file under its desired new name.  That is, the combination of the
two patches together performs the rename of c++defs over to cxxdefs when
the module is imported into the emacs tree.

> 
> Also, the patch in gnulib-local/modules/c++defs.diff would need to be
> updated from time to time, when c++defs in gnulib changes
> significantly, is that right?

Correct, although given the stability of c++defs, that is not likely to
be very often.

> 
> Finally, what is the file c++defs that will be patched by that patch?
> I see no such file in Emacs at the moment.

It's the file gnulib/modules/c++defs that tells gnulib-module how to
import all files related to the c++defs module.  But you are changing it
to be the cxxdefs module.  Gnulib-tool uses the combination of its own
module files, as patched by your local files, to decide what to apply to
your local tree.  After gnulib-tool is complete, you no longer need any
of the gnulib/modules files stored in the emacs tree, but just the
output.  Which means that after a all is said and done, the only
remaining file with + in the name is your instructions to gnulib-tool
(not part of the normal emacs build, but necessary for whoever reruns
the gnulib synchronization script), and everything else in the emacs
tree (which is actually part of the build) has already been renamed to
cxxdefs during the gnulib-tool synchronization.

>> If not, what's remaining?
> 
> Assuming this is acceptable to Stefan and Paul, all that's left is for
> me to understand the details about which I ask above, and then do all
> these changes.

And to make sure that in the future, none of the other 8.3 conflicts
that were pointed out by Jim end up being imported into emacs during a
subsequent gnulib-tool synchronization run.

-- 
Eric Blake   eblake@redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org