Hi Bob,
* Bob Friesenhahn wrote on Wed, Nov 07, 2007 at 04:01:47AM CET:
> On Tue, 6 Nov 2007, Ralf Wildenhues wrote:
> >
> >Yes. Maybe I should write a paper "nonrecursive make also considered
> >harmful" just to be able to point people at it. It's overhyped.
> >There is no need to be completely
On Tue, 6 Nov 2007, Ralf Wildenhues wrote:
Yes. Maybe I should write a paper "nonrecursive make also considered
harmful" just to be able to point people at it. It's overhyped.
There is no need to be completely nonrecursive. There's been a lot
Ralf,
Thanks for sharing your true feelings. I
On Wed, 2007-11-07 at 01:00 +, Harlan Stenn wrote:
> IME, that position is excessive. It was true, as far as I can recall,
> for SGI's make, but this is the first time this particular issue has
> bitten me (or any of the users of the package) in a *long* time.
Hm. Maybe automake works around
Paul,
Thanks for your response.
> On Tue, 2007-11-06 at 19:46 +, Harlan Stenn wrote:
> > I'm getting bitten by the VPATH-handling differences between FreeBSD's
> > make and gmake.
>
> The automake manual says (somewhere) that the only version of make that
> correctly supports out-of-the-tree
On Tue, 2007-11-06 at 19:46 +, Harlan Stenn wrote:
> I'm getting bitten by the VPATH-handling differences between FreeBSD's
> make and gmake.
The automake manual says (somewhere) that the only version of make that
correctly supports out-of-the-tree builds is GNU make. The VPATH
capability in
I'm getting bitten by the VPATH-handling differences between FreeBSD's
make and gmake.
I have a .y file and I currently distribute the bison-generated .[ch]
files in the distribution.
On a stock FreeBSD machine (at least) when doing a build outside of the
source tree, FreeBSD's make doesn't see t
* NightStrike wrote on Tue, Nov 06, 2007 at 07:33:04PM CET:
>
> I guess I misunderstood the purpose of automake in general. I
> understand that automake itself is portable, but is automake intended
> mainly for those projects which are themselves portable?
Well, not mainly, but there is certainl
NightStrike wrote:
> Regarding libtool, maybe I just don't understand how libtool works. I
> can't figure out how to use libtool to generate lib*.a. It seems
> intent on restricting outputs to only lib*.la. I eventually gave up
> and started manually invoking dlltool myself to build the lib*.a
On 11/6/07, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> * NightStrike wrote on Tue, Nov 06, 2007 at 07:09:21PM CET:
> > On 11/6/07, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> > > > Can you add to that also AM_DLLTOOLFLAGS?
> > >
> > > It's been mentioned before: Automake currently does not use d
* NightStrike wrote on Tue, Nov 06, 2007 at 07:13:58PM CET:
>
> The Automake manual makes reference to Peter Miller's paper
> (http://www.pcug.org.au/~millerp/rmch/recu-make-cons-harm.html). I've
> been trying to adopt those ideas as much as possible, and so far have
> succeeded in not requiring
* NightStrike wrote on Tue, Nov 06, 2007 at 07:09:21PM CET:
> On 11/6/07, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> > > Can you add to that also AM_DLLTOOLFLAGS?
> >
> > It's been mentioned before: Automake currently does not use dlltool.
[...]
> The benefit of having it be part of Automake is t
On 11/6/07, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> * NightStrike wrote on Tue, Nov 06, 2007 at 07:02:55PM CET:
> >
> > Is it possible to specify something like foo_CFLAGS for all libraries
> > that get installed into that directory, but not affect the general
> > case? Now yes, I can define
* NightStrike wrote on Tue, Nov 06, 2007 at 07:02:55PM CET:
>
> Is it possible to specify something like foo_CFLAGS for all libraries
> that get installed into that directory, but not affect the general
> case? Now yes, I can define my own variable called as such and
> include it on the CFLAGS li
On 11/6/07, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> > Can you add to that also AM_DLLTOOLFLAGS?
>
> It's been mentioned before: Automake currently does not use dlltool.
> What would AM_DLLTOOLFLAGS be for then? Support for it would be a null
> change. Just put $(AM_DLLTOOLFLAGS) into your se
Currently, it's possible to define flags for the general case and for
specific targets. For instance, the following:
AM_CFLAGS = -flag1
foo_LIBRARIES = liba.a libb.a
liba_a_SOURCES = a.c
liba_a_CFLAGS = $(AM_CFLAGS) -flag2
libb_a_SOURCES = b.c
libb_b_CFLAGS = $(AM_CFLAGS) -flag3
However, is it
* NightStrike wrote on Tue, Nov 06, 2007 at 05:36:11PM CET:
> I just came across the multilib section of the automake manual:
> http://www.gnu.org/software/automake/manual/automake.html#Multilibs
>
> How can I find the status on this? How "experimental" is "experimental"?
It's experimental. GCC
Hello Benoît,
* NightStrike wrote on Tue, Nov 06, 2007 at 03:29:05PM CET:
> On 11/6/07, Benoit SIGOURE <[EMAIL PROTECTED]> wrote:
> > Hi list,
> > would anyone be against the introduction of AM_LIBS / AM_LDADD
> > (before the release of 1.11) to be more consistent with the existing
> > AM_*flags?
I just came across the multilib section of the automake manual:
http://www.gnu.org/software/automake/manual/automake.html#Multilibs
How can I find the status on this? How "experimental" is "experimental"?
On 10/21/07, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> Hello whoever(?),
>
> * NightStrike wrote on Sun, Oct 21, 2007 at 07:13:19PM CEST:
> > If I wanted -pipe passed in to gcc all the time, do I put that in
> > AM_CPPFLAGS or AM_CFLAGS?
>
> You pass it to configure via CFLAGS, or CC:
> ./conf
On 11/6/07, Benoit SIGOURE <[EMAIL PROTECTED]> wrote:
> Hi list,
> would anyone be against the introduction of AM_LIBS / AM_LDADD
> (before the release of 1.11) to be more consistent with the existing
> AM_*flags?
Can you add to that also AM_DLLTOOLFLAGS?
Hi list,
would anyone be against the introduction of AM_LIBS / AM_LDADD
(before the release of 1.11) to be more consistent with the existing
AM_*flags?
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
PGP.sig
Description: This is a digitally signed message part
21 matches
Mail list logo
