[comp.emacs.xemacs] AUCTeX 11.84 released
matsl at xemacs.org
Tue Jan 23 03:43:35 EST 2007
>>>>> David Kastrup <dak at gnu.org> writes:
>> Mats Lidell writes:
>> > >>>>> Stephen writes:
>> > Stephen> I'm sure it can be done, ...
>> > Is it possible to describe, in a few lines, what the technical problem
>> > is in making the package build within the XEmacs Package Tree?
>> With accuracy, no. At one time, the AUCTeX build process required
>> running configure on the installation host. That would obviously
>> result in undistributable binary packages.
David> Which you do by calling
David> make FTPDIR=/tmp/auctex TAG=11.84 tarball
David> make FTPDIR=/tmp/auctex TAG=11.84 xemacs-package
David> Then you have a completely built XEmacs package in /tmp/auctex,
David> and an unpacked clean tarball in ./auctex-11.84.
Are you suggesting that this would be a good starting point for
inclusion in the XEmacs Package Tree?
David> And actually, it does not really require even that. It
David> suffices to take the finished XEmacs package distributed by
David> AUCTeX, since that contains everything that is to end up in the
David> XEmacs package from Sumo, in the right places.
The build procedure designed by the AUCTeX team is quite likely
perfect for its job, and built against the right version of the SUMO
package (there is an integration issue here right!?) it will be fine,
but that doesn't make me understand a bit what is the problem in
making it build within the XEmacs Package Tree.
David> It is an illusion to imagine that taking the identical files
David> from the source tarball instead of AUCTeX's binary XEmacs
David> package is somehow going to make a legal difference: the
David> copyrightable content is the same. In either case, XEmacs
David> central decides that it needs not distribute the build
David> infrastructure (whether from AUCTeX or from XEmacs) along with
David> the binary package in order to comply with the GPL.
I wasn't aware that there are legal issues here. Please explain?
More information about the XEmacs-Beta