Hello,
I have a binary that I use as a build tool only to build the rest of the
package and dont want to install it. Any ideas about how to write up a
Makefile.am for this?
Please reply to me directly as I am not on this list.
Thanks,
Laszlo
> I have a binary that I use as a build tool only to build the rest of the
> package and dont want to install it. Any ideas about how to write up a
> Makefile.am for this?
Laszlo,
There is a noinst label for this. For instance, in your
Makefile.am :
noinst_PROGRAMS = yourbintool
which works
Stephane Genaud wrote:
>
>
> > I have a binary that I use as a build tool only to build the rest of the
> > package and dont want to install it. Any ideas about how to write up a
> > Makefile.am for this?
>
> Laszlo,
>
> There is a noinst label for this. For instance, in your
> Makefile.am :
>
| > How about merging AC_PROG_CPP and AC_PROG_CC together?
| >
| > What's the point of keeping the two of them?
| * Some tools (eg. imake) apply cpp as macro-processor, even if cc is
| not available on a particular installation. Other tools might want
| to apply these tools even i
It would be great if one could add -I options to aclocal by just placing
macros in configure.ac, like:
AC_CONFIG_MACRO_DIR(conf/m4macros)
That way I could run aclocal without having to remember the dirs or wrap
the invocation in a script (aclocal scans configure.ac anyways). Would
this be easil
On Wed, Jun 13, 2001 at 11:44:52AM +0300, Kalle Olavi Niemitalo wrote:
> This bug is also causing the @TRUE@ conditions reported by
> Richard Boulton in "Bug with conditionals. [PATCH]".
You're right, this does seem to be the main cause of the problem I
reported.
I tried fixing the problem (by p
Richard Boulton <[EMAIL PROTECTED]> writes:
> On Wed, Jun 13, 2001 at 11:44:52AM +0300, Kalle Olavi Niemitalo wrote:
>> This bug is also causing the @TRUE@ conditions reported by
>> Richard Boulton in "Bug with conditionals. [PATCH]".
>
> You're right, this does seem to be the main cause of the p
Dear Friend,
AS SEEN ON NATIONAL TV :
''Making over half million dollars every 4 to 5 months from your
home for an investment of only $25 US Dollars expense one time''
THANKS TO THE COMPUTER AGE AND THE INTERNET!
=
BE A MILLIONAIRE LIKE OTHERS WITH
On Thu, Jun 14, 2001 at 03:17:38PM -0500, Raja R Harinath wrote:
> Isn't it cleaner to use
>
> sub conditions_true_when(\@@)
> {
> my ($condsref, @whens) = @_;
>
[snip]
>
> >- if ! conditionals_true_when ((@parent_conds), ($vcond));
> >+ if ! conditionals_true_when ([@parent_
Richard Boulton <[EMAIL PROTECTED]> writes:
[snip]
> (ii) is fixed by redefining the behaviour of conditionals_true_when() such
> that it returns TRUE if all the @CONDS are true for a condition in @WHENS.
> The behaviour when WHENS is empty is also altered to be more logical (this
> is where the F
In a Makefile which is created using automake-1.4f, libtool is not
removed by distclean-am, in fact, it doesn't seem to be removed at
all. In automake-1.4-p4, libtool is removed by distclean-am. These
are the libtool related macros which I use:
AC_LIBTOOL_DLOPEN
AC_DISABLE_SHARED
AC_PROG_LIBTOO
> "Steve" == Steve M Robbins <[EMAIL PROTECTED]> writes:
Steve> Given the following Makefile.am
Steve> bin_PROGRAMS = foo
Steve> foo_SOURCES = foo.c sub/foo2.c
Steve> it turns out that "foo.c" is compiled using $(COMPILE), and hence
Steve> includes AM_CFLAGS. However, "foo2.c" is compiled
> "Richard" == Richard Boulton <[EMAIL PROTECTED]> writes:
Richard> i) variable_conditions_reduce() currently checks conditions
Richard> for redundancy against only those conditions which it has
Richard> already checked, rather than against all the conditions it
Richard> hasn't yet discarded.
> "Rusty" == Rusty Ballinger <[EMAIL PROTECTED]> writes:
Rusty> Is there a simpler way to do this? It seems like you'd wind up
Rusty> doing a lot of work which automake already does.
Another method is to use a macro (available at the macro archive) to
expand $prefix or whatever at configure
> "Kevin" == Kevin Dalley <[EMAIL PROTECTED]> writes:
Kevin> If AC_CONFIG_AUX_DIR is not used, and version.texi is in a doc
Kevin> directory, than "automake -a" installs mdate-sh in top_srcdir,
Kevin> but the Makefile.in in the doc directory tries to use mdate-sh
Kevin> in srcdir, which mdate
We're starting to get patches which can't be checked in until
post-1.5. I'm not even really interested in reviewing them until
then.
I was thinking I could create a new `patch' category in the automake
Gnats and ask people to put such patches there as attachments. What
do people think of this?
> "Steve" == Steve M Robbins <[EMAIL PROTECTED]> writes:
Steve> The upshot is that "foo.c" is compiled using AM_CFLAGS but NOT
Steve> foo_CFLAGS, while "foo2.c" is compiled NOT using AM_CFLAGS but using
Steve> foo_CFLAGS.
I'm checking in a fix for this.
Tom
Tom Tromey wrote:
>
> > "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
>
> > "Nathan" == Nathan Neulinger writes:
> Nathan> Would y'all consider extending the license exception to
> Nathan> include the 'missing' script as well? (I'm referring to the
> Nathan> exception that allows
> "Lars" == Lars J Aas <[EMAIL PROTECTED]> writes:
Lars> It would be great if one could add -I options to aclocal by just placing
Lars> macros in configure.ac, like:
Lars> AC_CONFIG_MACRO_DIR(conf/m4macros)
That might be nice.
I forget though what Akim has in mind for this for autoconf.
The
> "Kevin" == Kevin Dalley <[EMAIL PROTECTED]> writes:
Kevin> In a Makefile which is created using automake-1.4f, libtool is not
Kevin> removed by distclean-am, in fact, it doesn't seem to be removed at
Kevin> all. In automake-1.4-p4, libtool is removed by distclean-am. These
Kevin> are the
On Thu, Jun 14, 2001 at 06:51:09PM -0600, Tom Tromey wrote:
> > "Steve" == Steve M Robbins <[EMAIL PROTECTED]> writes:
>
> Steve> Given the following Makefile.am
> Steve>bin_PROGRAMS = foo
> Steve>foo_SOURCES = foo.c sub/foo2.c
> Steve> it turns out that "foo.c" is compiled us
Lars> It would be great if one could add -I options to aclocal by just placing
Lars> macros in configure.ac, like:
Lars> AC_CONFIG_MACRO_DIR(conf/m4macros)
I would like that too.
Tom> You can use ACLOCAL_AMFLAGS (bad name, I know) in Makefile.am.
Uh, like this?:
ACLOCAL_AMFLAGS = -I config
> "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes:
>> How about merging AC_PROG_CPP and AC_PROG_CC together? What's the
>> point of keeping the two of them?
Pavel> My concern is compatibility. There is no real reason to test
Pavel> for one but not the other, but if we go ahead and merge
> "Ralf" == Ralf Corsepius <[EMAIL PROTECTED]> writes:
Ralf> This thought however raises another question: Why does
Ralf> AC_PROG_CPP exist at all?
Ralf> I would assume: * Some autoconf-users wanted to use CPP without
Ralf> CC (I have even seen cases were a host's native cpp have been
Ralf>
Sounds like this could be fixed in depcomp?
Derek
--
Derek Price CVS Solutions Architect ( http://CVSHome.org )
mailto:[EMAIL PROTECTED] CollabNet ( http://collab.net )
--
"Very funny Scotty, now beam down my clothes!"
Hi,
I'm Trying to update an old SCO unixwa
> "Derek" == Derek R Price <[EMAIL PROTECTED]> writes:
Derek> Sounds like this could be fixed in depcomp?
Maybe...
Stephen> I'm Trying to update an old SCO unixware 2 box...Currently I
Stephen> have CVS 1.10.8 there. (Yeah, shame on me)
Stephen> The cc's -o option refuses to overwrite exis
Hello, Akim!
> Pavel> If you feel that you can handle it feel free to merge. It
> Pavel> should be done earlier or later anyways.
>
> So you share my opinion?
I share your opinion that AC_PROG_CPP and AC_PROG_CC should be merged
eventually. Whether it should be done before Autoconf-2.51 is anoth
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
> "Nathan" == Nathan Neulinger writes:
Nathan> Would y'all consider extending the license exception to
Nathan> include the 'missing' script as well? (I'm referring to the
Nathan> exception that allows distributing autoconf support fil
28 matches
Mail list logo
