Joel> i'd love to see lex/yacc rules use .cpp
You can do this by naming your yacc file "foo.ypp".
Tom
On Jul 19, [EMAIL PROTECTED] twisted the bits to say...
Lassi> I would also recommend against .C as the C++ file extension -- VC++ is a
Lassi> combined C and C++ compiler and the file system is case insensitive.
Lassi> (Alternatively, autoconf should use the -Tc/-Tp options with that
Lassi> compi
Peter> Automake-generated makefiles should somehow be coping with the
Peter> possibility that install-info is not available. Currently, the
Peter> uninstall target of CVS Autoconf is doesn't work for me because
Peter> of this. (The `info' RPM somehow placed it at
Peter> /sbin/install-info.)
Can
Alex> I've sent them in... but I've not heard anything back (they went
Alex> to the address in assign.future whilst RMS was away). I can
Alex> resend them if necessary.
Sometimes it takes a while.
Alex> I think its sufficiently different, I did try mangling one file
Alex> for both situations, bu
> Nope, I think this is a case where we should mandate an extension.
> For instance, I'm very much for .f77 for Fortran 77, and not .f, so
> that for instance Automake knows what is the compiler to run if there
> is F77, F90 and the preprocessed variations.
The de-facto standard seems to be that
Automake-generated makefiles should somehow be coping with the possibility
that install-info is not available. Currently, the uninstall target of
CVS Autoconf is doesn't work for me because of this. (The `info' RPM
somehow placed it at /sbin/install-info.)
--
Peter Eisentraut
Tom Tromey writes:
> Alex, did you file the papers with the FSF? I don't recall seeing a
> message from them. The patches can't go in until the paperwork
> clears. If you did this in the past and I forgot, please accept my
> apologies.
>
I've sent them in... but I've not heard anything b
Alex> If I was to do this, would someone with CVS access consider
Alex> applying them in a timely manner? I suspect I might go mad
Alex> trying to maintain five source trees for any length of time.
Akim> I'm OK with handling this, but I don't feel fully qualified. Tom,
Akim> Alexandre, may I? I
Akim Demaille writes:
> > "Alex" == Alex Hornby <[EMAIL PROTECTED]> writes:
>
> Alex> If I was to do this, would someone with CVS access consider
> Alex> applying them in a timely manner? I suspect I might go mad
> Alex> trying to maintain five source trees for any length of time.
>
>
> "Alex" == Alex Hornby <[EMAIL PROTECTED]> writes:
Alex> If I was to do this, would someone with CVS access consider
Alex> applying them in a timely manner? I suspect I might go mad
Alex> trying to maintain five source trees for any length of time.
I'm OK with handling this, but I don't fee
I updated to automake in the CVS and now I am getting a bunch of
warnings like this when I run make.
make[2]: Entering directory `/usr/local/project/build/tkgs/src'
Makefile:546: warning: overriding commands for target `libtkgs_la-tkgs.o'
Makefile:426: warning: ignoring old commands for target `l
> Tom, have you taken a look at the source file extension problem? It
> seems we don't know what sane extension we could use to compile C++
> source files. For instance VC++ rejects .cc.
AFAIK, there is no one extension that all C++ compilers will be happy
with. After a bit of research we chos
Dear Akim Demaille, you wrote on Today:
> See the patch: f77 is preferred. It is more discriminant. But I
> might be wrong, I don't really have a strong Fortran experience :)
All I can say is neither g77 nor any of the other compilers I know
(among which the native ones on IRIX, SOlaris and AI
| Dear Akim Demaille, you wrote on Today:
| > Maybe we should AC_SUBST the result? This might be important for
| > Automake to see if it needs a wrapper for compilers which refuse the
| > traditional extensions?
|
| > I've tested this patch like this:
| >
| > /tmp % cat /tmp/f77
> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes:
Akim> What would Automake (or missing) need to know?
Tom> Whether the compiler can support the extensions actually in use
Tom> by the program. This is an ugly problem because it involves
Tom> feedback from Makefile.am to configure.
Nope, I
Dear Akim Demaille, you wrote on Today:
> Maybe we should AC_SUBST the result? This might be important for
> Automake to see if it needs a wrapper for compilers which refuse the
> traditional extensions?
> I've tested this patch like this:
>
> /tmp % cat /tmp/f77
Akim> Same for C++, Automake should, IMHO, require a single extension.
Instead of that we can just document the portable one. Being forced
to rename all the files in your project when you know it will never be
a problem for you would be annoying.
For instance, libgcj uses ".cc". We don't care
Martin> .c.o: $(CC) $(CFLAGS) ... @CC_C_O@ $<
Tom> This won't be sufficient. Automake will need more information.
Akim> Such as?
Merely having a subst like that isn't good enough because automake
still has to support the general case. So instead automake would want
some value it can check and
> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes:
Martin> And then, for full functionality, automake should use that
Martin> variable in generating rules, right?
Martin> .c.o: $(CC) $(CFLAGS) ... @CC_C_O@ $<
Tom> This won't be sufficient. Automake will need more information.
Such as?
Tom
Akim Demaille writes:
> Hi Alex,
>
> I'm no Automake maintainer, so you may just forget everything I will
> say :)
>
> I think your patch addresses a very interesting issue, and it would be
> great to apply it, but it's getting very big. If there are
> independent chunks in it, you shou
Martin> And then, for full functionality, automake should use that
Martin> variable in generating rules, right?
Martin> .c.o:
Martin> $(CC) $(CFLAGS) ... @CC_C_O@ $<
This won't be sufficient.
Automake will need more information.
Tom
> Akim Demaille writes:
>
> > But precisely because of your needs, don't you need an output variable
> > or something instead of the CPP symbol?
>
> Certainly so.
And then, for full functionality, automake should use that variable
in generating rules, right?
.c.o:
$(CC) $(CFLAGS) ..
Hi Alex,
I'm no Automake maintainer, so you may just forget everything I will
say :)
I think your patch addresses a very interesting issue, and it would be
great to apply it, but it's getting very big. If there are
independent chunks in it, you should try to keep them separate.
Also, if possib
23 matches
Mail list logo
