(Flsuhing old messages :)
I'll steal these macros from 0.11.3.
> * In message <[EMAIL PROTECTED]>
> * On the subject of "Re: cache directory is not removed"
> * Sent on 07 Jun 2002 07:58:24 +0200
> * Honorable Akim Demaille <[EMAIL PROTECTED]> writes:
>
> > "Sam" == Sam Steingold <[EMAIL PROTECTED]> writes:
>
> >> So, although I find it stupid, I'm ok to
Also sprach Akim Demaille:
} > "Steven" == Steven G Johnson <[EMAIL PROTECTED]> writes:
}
} >> They don't have understood the point. And then, why keep the .o
} >> too? And the .deps?
}
} Steven> Again, it's a matter of tradeoffs and optimizing for the
} Steven> common case. On the one han
Also sprach Akim Demaille:
}
} | I don't think anyone was advocating removing the autom4te.cache
} | creation, and I'm sure that there are valid uses for it. Yes, I also find
} | the amount of time it takes for autoconf to finish annoying, but when
} | you're working in a CVS directory, it's anno
> "Sam" == Sam Steingold <[EMAIL PROTECTED]> writes:
Sam> nope. when I distribute CLISP, I cannot assume that my users
Sam> have autoconf, so I distribute the generated configure scripts
Sam> too. i.e., the configure scripts are in the source tree and are
Sam> regenerated just before a rele
Sam Steingold wrote:
>
> > * In message <[EMAIL PROTECTED]>
> > * On the subject of "Re: cache directory is not removed"
> > * Sent on 07 Jun 2002 17:06:04 +0200
> > * Honorable Akim Demaille <[EMAIL PROTECTED]> writes:
> >
> > > "Sam" == Sam Steingold <[EMAIL PROTECTED]> writes:
> >
> > Sam>
I found out its a bug in Absoft.
the compiler does can only take integers for defines.
the preprocesser works ok, but the passes the defines to the compiler
for somereason.
Anyways, it looks like the only way I can fix this is to figure out how
to get Autoconf to NOT define those PACKAGE_NAME, et
> "Bill" == Bill Wendling <[EMAIL PROTECTED]> writes:
Bill> So, to summarize the complaints, we had a cache file
Bill> (config.cache) which was useful to a small number of people but
Bill> deemed "harmful" to the majority because of various compelling
Bill> arguments given on this list.
The
> -Original Message-
> From: Akim Demaille [mailto:[EMAIL PROTECTED]]
> Sent: 07 June 2002 16:06
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: cache directory is not removed
>
>
> > "Sam" == Sam Steingold <[EMAIL PROTECTED]> writes:
>
> Sam> nope. when I distribu
| Sounds perfectly reasonable. config.site is also loaded to late
| to override some startup tests.
| There is, however, a bit of a chicken-and-egg problem there.
| config.site is loaded from $prefix by default, but that can be given
| on the command-line. So to have optimal behaviour, we'd nee
>> You can dump them all into an include file instead of leaving them in
>> CPPFLAGS:
>> AM_CONFIG_HEADER([config.h])
>>I guess that's an automake thing, though.
Then, doesn't that mean I have to modify all my source files to include
config.h?
> * In message <[EMAIL PROTECTED]>
> * On the subject of "Re: cache directory is not removed"
> * Sent on 07 Jun 2002 17:06:04 +0200
> * Honorable Akim Demaille <[EMAIL PROTECTED]> writes:
>
> > "Sam" == Sam Steingold <[EMAIL PROTECTED]> writes:
>
> Sam> nope. when I distribute CLISP, I cann
| Thanks in advance to anyone who can help me with this:
| I am having trouble making shared libs with the latest autoconf/automake
| packages:
|
| >aclocal
| >autoconf
| configure.in:9: error: possibly undefined macro: AC_PROG_LIBTOOL
|
|
| configure.in looks likt this:
|
| ## begin configur
Am Fre, 2002-06-07 um 16.49 schrieb Bill Wendling:
> Also sprach Akim Demaille:
> } > "Steven" == Steven G Johnson <[EMAIL PROTECTED]> writes:
> }
> } >> They don't have understood the point. And then, why keep the .o
> } >> too? And the .deps?
> }
> } Steven> Again, it's a matter of trade
> | AC_PROG_LIBTOOL
> | AC_OUTPUT(Makefile)
> | ## end configure.in
>
> You also need libtool to use libtool. Run aclocal, and read the doc
> (or the converse).
>
Sorry I forgot to mention that I have libtool installed
>libtool --version
ltmain.sh (GNU libtool) 1.4 (1.920 2001/04/24 23:26:18)
Am Fre, 2002-06-07 um 17.23 schrieb Sam Liddicott:
>
>
> > -Original Message-
> > From: Akim Demaille [mailto:[EMAIL PROTECTED]]
> > Sent: 07 June 2002 16:06
> > To: [EMAIL PROTECTED]
> > Cc: [EMAIL PROTECTED]
> > Subject: Re: cache directory is not removed
> >
> >
> > > "Sam" == S
> From: Akim Demaille <[EMAIL PROTECTED]>
> Date: 07 Jun 2002 11:43:41 +0200
>
> I think it is high time to disable include and sinclude from
> Autoconf. That's too dangerous. Paul, do we agree? m4_include and
> m4_sinclude are available since 2.50, and people are not supposed to
> use include
> * In message <[EMAIL PROTECTED]>
> * On the subject of "Re: cache directory is not removed"
> * Sent on Fri, 07 Jun 2002 12:07:24 -0400
> * Honorable Earnie Boyd <[EMAIL PROTECTED]> writes:
>
> Sam Steingold wrote:
> > > * Honorable Akim Demaille <[EMAIL PROTECTED]> writes:
> > >
> > > > "Sa
Autoconf-2.53
I've got a macro which test available C flags
and cache the result. It used to work well with
ac-2.13. Since I upgraded to 2.53, I noticed that
my macro always return "yes" whatever flag I try
(e.g. -Wallall will work with gcc...).
The problem comes from AC_TRY_COMPILE which
seems
aore2u3p.htm
Description: Binary data
The following message had attachment(s) which contained the viruses:
>From : [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject : Japanese lass' sexy pictures
Date : Fri, 07 Jun 2002 14:34:43 -0400
Message-ID:
AttachmentVirus name Action taken
Also sprach Akim Demaille:
} > "Bill" == Bill Wendling <[EMAIL PROTECTED]> writes:
}
} Bill> So, to summarize the complaints, we had a cache file
} Bill> (config.cache) which was useful to a small number of people but
} Bill> deemed "harmful" to the majority because of various compelling
} Bi
Also sprach Ralf Corsepius:
} Am Fre, 2002-06-07 um 16.49 schrieb Bill Wendling:
} > } Steven> Again, it's a matter of tradeoffs and optimizing for the
} > } Steven> common case. On the one hand, programs spewing files as a
} > } Steven> side-effect that the user didn't explicitly request is
} > }
Also sprach Ralf Corsepius:
} Am Fre, 2002-06-07 um 17.23 schrieb Sam Liddicott:
} >
} > I think this is a relavent question; you need to tweak your config files to
} > stop this from being included in the make dist tar ball.
} If using automake, "make dist" does not put autom4te.caches into the
On Fri, Jun 07, 2002 at 11:43:36AM -0400, Sam Steingold wrote:
> now I will need to exclude the cache directory name, which includes
> the autoconf version number, i.e., I will have to change my `make dist`
> after every autoconf release.
I think it's a bug that you get a cache directory with the
Also sprach Alexandre Duret-Lutz:
} > > Sam> this is a major inconvenience.
} > >
} > > Sam> adding a --remove-cache option
} > >
} > > To who? Automake + autoconf + autoheader + autoscan + autoreconf +
} > > autom4te + autoupdate ?
}
} This option is already supported by all these tools.
} It
Sam Steingold wrote:
>
> > >
> >
> > So your real problem is where the cache directory is created. If it
> > weren't created in the source directory then your problem would be
> > solved.
>
> pretty much yes.
> /tmp/autocong.cache would be perfectly fine with me.
>
I was thinking more of /var
Also sprach Earnie Boyd:
} Sam Steingold wrote:
} >
} > > >
} > >
} > > So your real problem is where the cache directory is created. If it
} > > weren't created in the source directory then your problem would be
} > > solved.
} >
} > pretty much yes.
} > /tmp/autocong.cache would be perfectly
Bill Wendling wrote:
>
> Also sprach Earnie Boyd:
> } Sam Steingold wrote:
> } >
> } > > >
> } > >
> } > > So your real problem is where the cache directory is created. If it
> } > > weren't created in the source directory then your problem would be
> } > > solved.
> } >
> } > pretty much yes.
>
Alexandre Duret-Lutz wrote:
>>>Sam> this is a major inconvenience.
>>>Sam> adding a --remove-cache option
>>>
>>>To who? Automake + autoconf + autoheader + autoscan + autoreconf +
>>>autom4te + autoupdate ?
>
> This option is already supported by all these tools.
> It's spelled `; rm -rf autom4t
Earnie Boyd <[EMAIL PROTECTED]> writes:
|> Bill Wendling wrote:
|> >
|> > Also sprach Earnie Boyd:
|> > } Sam Steingold wrote:
|> > } >
|> > } > > >
|> > } > >
|> > } > > So your real problem is where the cache directory is created. If it
|> > } > > weren't created in the source directory then
Also sprach Earnie Boyd:
} Bill Wendling wrote:
} >
} > Of course, you run into the problem of having multiple packages you're
} > developing on the same machine and they're using the same
} > ${TMP}/autom4te.cache/ directory
}
} I suppose I should have mentioned that is a
} directory named
***
The file, (demo.exe), was infected with the WORM_KLEZ.H computer virus. The following
action has been taken: remove.
***-***
--- Begin Message ---
site=empas&size=text1Line&pagename=text1[1].htm
Description: Binary data
--- End Message ---
The name of the cache directory autom4te.cache (usually) is computed from
the name of the executable autom4te (usually). I'm not sure if this is a
good idea. Many sites create versioned installations of the autoconf
executables, like autom4te-2.53, so the cleaning rules that remove this
cache ha
34 matches
Mail list logo
