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
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
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
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
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
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..
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 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
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
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 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
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
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
13 matches
Mail list logo