> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> On Apr 17, 2001, Akim Demaille <[EMAIL PROTECTED]> wrote:
>> * automake.in (¯o_define): User variables can be first defined
>> with `+='.
Alexandre> My impression is that, in this case, the macro should add
Alexandre> to
On Apr 18, 2001, Akim Demaille <[EMAIL PROTECTED]> wrote:
> Unfortunately it is quite unrealistic wrt the implementation: Automake
> values are read _after_ Makefile.am was. Supporting this would be
> hard, and I am not sure it would bring really bonus.
How about this: when you find FOO += bar
- Original Message -
From: "Akim Demaille" <[EMAIL PROTECTED]>
To: "Alexandre Oliva" <[EMAIL PROTECTED]>
Cc: "Robert Collins" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Wednesday, April 18, 2001 5:53 PM
Subject: Re: problem: unitialized +=
> > "Alexandre" == Alexandre Oliva <[EMA
Tim Van Holder wrote:
>
> > You're right: line endings are to blame... the funny thing is that I got
> > the sources from a Linux CVS server, and the uncorrect line endings seem
> > to have been added during the dowloading... (actually I used WinCVS, so
> > this is quite likely).
>
> If you're u
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> On Apr 18, 2001, Akim Demaille <[EMAIL PROTECTED]> wrote:
>> Unfortunately it is quite unrealistic wrt the implementation:
>> Automake values are read _after_ Makefile.am was. Supporting this
>> would be hard, and I am n
> "Robert" == Robert Collins <[EMAIL PROTECTED]> writes:
Robert> Is there are reason that the automate values cannot all be +=,
Robert> with a flag to ignore the value completely if the user uses =
Robert> not += ?
Sorry, I don't understand what you mean.
Robert> Without handling this in th
- Original Message -
From: "Akim Demaille" <[EMAIL PROTECTED]>
To: "Robert Collins" <[EMAIL PROTECTED]>
Cc: "Alexandre Oliva" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, April 18, 2001 7:00 PM
Subject: Re: problem: unitialized +=
> > "Robert" == Robert Collins <[EMAIL P
The generation of the .dep/*.P files is incorrect on my Red Hat
7.1beta (with imfamous gcc 2.96). When I configure in build
directory outside of source directory, I get a first line like
../../hippodraw/src/AxisModelBase.lo ../../hippodraw/src/AxisModelBase.o ;
(i.e. pointing to the source
Robert Boehne wrote:
>
> Hello!
>
> Current CVS sources of Automake leave @_am_quote@
> un-substituted in Makefile's causing make to fail
> if dependencies are requested.
> This is a recent problem, it's existed in CVS for
> only a few days (don't know exactly though). I did have
> a version
Hello,
There is a bit of a problem in CVS Automake (Today's) when
--disable-dependency-tracking is specified to configure.
If dependency tracking rules have been added to Makefile.in,
the rules created have @AMDEPBACKSLASH@ at the end of the
lines that tell depcomp the required variables source,
Unless specifically stated in the module itself, core modules are licensed
under the same terms as Perl itself, i.e. you may use either the GPL or
the AL, whichever suits your needs best.
Someone pointed out that the statement of CPAN policy could be made
more explicit by changing a c
We would like to have some advice from you about a license issue. In
short, we would like to use a modified version of a Perl core module,
which means we need it to be GPL.
I don't understand the scenario clearly, so I don't know the answer.
Who initially wrote this module? What li
On Wed, Apr 18, 2001 at 10:58:11PM -0600, Richard Stallman wrote:
> We would like to have some advice from you about a license issue. In
> short, we would like to use a modified version of a Perl core module,
> which means we need it to be GPL.
>
> I don't understand the scenario cle
13 matches
Mail list logo
