On Thu, 21 May 2009, Ralf Wildenhues wrote:
It seems not easy to please you. :-)
I am a PITA. :-)
A while ago you (IMHO rightfully) complained about too much email coming
your way, with duplicates due to cross-posting to more than one mailing
list increasing the pressure even more. I can o
Hi Bob, all,
* Bob Friesenhahn wrote on Sun, May 17, 2009 at 10:43:51PM CEST:
>
> P.S. I am pretty pissed that almost all recent discussion of automake
> major features and direction has apparently taken place on the
> automake-patches list rather than the automake list where it belongs.
> N
Hi Bob,
On 5/17/2009 11:05 PM, Bob Friesenhahn wrote:
On Mon, 18 May 2009, Ralf Wildenhues wrote:
You can use
AM_SILENT_RULES
Worked! Thanks!
Unfortunately, it does not silence the warnings from my code.
Forgive me, but do you really want it to do this?
Of course, if you want to permane
On Mon, 18 May 2009, Ralf Wildenhues wrote:
You can use
AM_SILENT_RULES
Worked! Thanks!
Unfortunately, it does not silence the warnings from my code.
I should open a new discussion thread on the autoconf list regarding
the ability to obtain version and other package information from
outsi
Hi Bob,
* Bob Friesenhahn wrote on Sun, May 17, 2009 at 10:43:51PM CEST:
> I see that the only way to request the new `silent-rules' feature is by
> using the new form of AM_INIT_AUTOMAKE to pass the option. Since my
> package can not use the new form of AM_INIT_AUTOMAKE, then it can not
> req
On Sun, 17 May 2009, Bob Friesenhahn wrote:
I still owe you large quantities of beer. However, in order to clarify, I
would like to be able to execute configure script shell script code (more
like a configure test) and not generate a new configure script just because
the version has changed.
On Sun, 17 May 2009, Peter O'Gorman wrote:
Hi Bob,
You can use m4_easycmd to run your scripts at autoconf time. E.g. (from
autoconf itself):
AC_INIT([GNU Autoconf],
m4_esyscmd([build-aux/git-version-gen .tarball-version]),
[bug-autoc...@gnu.org])
I still owe you large quantities o
On Sun, 17 May 2009, NightStrike wrote:
On Sun, May 17, 2009 at 4:43 PM, Bob Friesenhahn
wrote:
I see that the only way to request the new `silent-rules' feature is by
using the new form of AM_INIT_AUTOMAKE to pass the option. Since my package
can not use the new form of AM_INIT_AUTOMAKE, the
Bob Friesenhahn wrote:
> It does not make sense to manually edit configure.ac each time a new
> package needs to be produced.
>
> Is there a way that some of my own script code can be executed prior to
> AC_INIT and a way to pass this information in a shell variable to
> AC_INIT? If so, then I c
On Sun, May 17, 2009 at 4:43 PM, Bob Friesenhahn
wrote:
> I see that the only way to request the new `silent-rules' feature is by
> using the new form of AM_INIT_AUTOMAKE to pass the option. Since my package
> can not use the new form of AM_INIT_AUTOMAKE, then it can not request
> `silent-rules'.
On Sun, 2009-05-17 at 15:43 -0500, Bob Friesenhahn wrote:
> The reason why my package can not use AC_INIT is that the package
> version information is (often) computed by shell script code based on
> the last entry in the project ChangeLog or other information. It is
> (apparently) not possibl
Bob Friesenhahn writes:
> The reason why my package can not use AC_INIT is that the package
> version information is (often) computed by shell script code based on
> the last entry in the project ChangeLog or other information. It is
> (apparently) not possible for user-provided script code to b
I see that the only way to request the new `silent-rules' feature is
by using the new form of AM_INIT_AUTOMAKE to pass the option. Since
my package can not use the new form of AM_INIT_AUTOMAKE, then it can
not request `silent-rules'.
The reason for this limitation is that using the new form o
13 matches
Mail list logo
