First, have a look which autoconf you're really running, with
$ which autoconf
or
$ type -a autoconf
I'll bet you find an old autoconf, probably in /usr/bin.
If that is the case, you have an old autoconf installation.
You can either modify your PATH so the new one is found before the old one
(but
On Thu, 6 Feb 2003, VISHWANATH B.V. wrote:
> There are some .cc files in a directory and some more .cc files in a
> directory under this. Whenever i do a make from the parent directory, it
> enters the sub directory and compiles SOME of the files in that directory
> and returns to the parent dir
On Thu, 6 Feb 2003, Alexandre Duret-Lutz wrote:
> As English is obviously not my mother tongue, and because I know
> some people have strong opinions about some of the issues
> discussed, I'd appreciate any comments.
Don't beat yourself up too much - your english is fine :)
> Cheerio,
^^^
Yo
Though I really don't think it's a good idea, have you tried just adding
install : check to your Makefile.am?
Anyways, the reason I don't think it's a good idea is that it will break
cross-compiling, as your test programs will probably not run on the build
host in that case..
HTH
rlc
NB: I'v
On Tue, 25 Mar 2003, Dr. David Kirkby wrote:
> Ronald Landheer-Cieslak wrote:
> > Anyways, the reason I don't think it's a good idea is that it will break
> > cross-compiling, as your test programs will probably not run on the build
> > host in that case..
> Can
On Mon, 31 Mar 2003, Dale E Martin wrote:
> Am I not getting some fundamental concept of the intention of config.h
> files?
Yep - see below.
> Here's my problem; I've got several projects that depend on each other;
> several libraries that depend on each other in an orderly fashion. All of
> them
Hello Bob,
What I usually do for generated source files is set the generated files in
the sources as I would any other and add a rule to generate them if need
be - and add the original files to EXTRA_DIST.
This will leave them there on `make clean` and distribute them as well as
the sources' s
On Wed, 2 Apr 2003, Dale E Martin wrote:
> > > "make install" clutils is installing it's generated config.h, which has
> > ^
> > Don't do that.
> Meaning that none of my headers can #inlude "config.h"? That seems
> ludicrous to me.
OK..
On Tue, 17 Jun 2003, Karl Berry wrote:
> comes from the Gnits standards.
> There is no such thing as "Gnits standards". I was/am a founding member
> of "gnits" (which was just a few friends talking informally), and I can
> state this authoritatively :).
Perhaps you should tell the people behin
Changelogs are *not* a lot of work: they *save* a lot of work!
Just my personal opinion, of course, but this is how *I* work:
1. make changes
2. diff with current CVS > patch
3. read patch and write the changelog for the patch
4. attach patch to the changelog and save it in my personal patch archi
That is actually a very good idea!
Thanks
rlc
On 19 Jun 2003, Thien-Thi Nguyen wrote:
>[EMAIL PROTECTED]:
>
>If you have any advice or ways to streamline the process I would very
>much like to hear it.
>
> spend one hour a week as a group reading change logs (and only change
> log
On Wed, 25 Jun 2003 [EMAIL PROTECTED] wrote:
> This overhead will take work and commitment from people. How much
> improvement can this deliver?? 10%? 50%? 500%?
Let me put it this way: writing Changelogs, though it does take a
commitment, has saved me (personally) a lot of time. I've been able t
I'm by no means an automake developer, but what you're looking for is
already done by Libtool.
File: libtool.info, Node: Link mode
`-rpath LIBDIR'
If OUTPUT-FILE is a library, it will eventually be installed in
LIBDIR. If OUTPUT-FILE is a program, add LIBDIR to the run-time
path
13 matches
Mail list logo
