This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: license of config-ml.in and symlink-tree
>>> "Alexandre" == Alexandre Oliva <aoliva@redhat.com> writes:
Alexandre> On Jul 23, 2003, Alexandre Duret-Lutz <aduret@src.lip6.fr> wrote:
>> config-ml.in (and thus symlink-tree) is used outside GCC by
>> other packages building multilibs.
Alexandre> Oh my God! Just now that we're looking into getting rid of
Alexandre> config-ml.in?
I'm pretty sure that has been the case for a while.
>> I'm also considering distributing these files with Automake,
>> so that Automake can exercise multilib rules in its test
>> suite
Alexandre> Please don't.
Automake used to support for multilib rules. I think it worked
at some point (in 1.4 perhaps) but then it broke and we didn't
notice it because the Automake test suite was not checking
multilib support. Also, until recently nobody reported the
failure. (I guess the multilibs users are the kind of people
who either work around Automake's bugs silently, or to stick to
old versions until things get magically fixed.)
Today Automake has a test case and the rules have been fixed. I
was planning to put the fix and the test in Automake 1.7.7. But
I can't have a test case without distributing config-ml.in and
symlink-tree.
What would you recommend? That Automake just ship config-ml.in
and symlink-tree but do not install them? I'd hate ship the fix
without the test case.
Alexandre> We should revamp the way we do multilibs to do it
Alexandre> properly (i.e., in the top level, without requiring
Alexandre> any specific changes to the directories that may be
Alexandre> built multiple times). Maybe automake could then
Alexandre> adopt a similar solution.
Has this been discussed somewhere ? Maybe this can be worked
out for Automake 1.8.
[...]
Alexandre> adding the exception would be a license change, so
Alexandre> the FSF should be asked about it. Will you please
Alexandre> ask them which license they'd like to use for these
Alexandre> programs?
Ok. The ticket is [gnu.org #56966]. I'll forward the answer
when I get one.
--
Alexandre Duret-Lutz