Hello,
I helped out with a a build system and switching to libtool for a shared
library and am now having the following problem. After building but
before installing, the program used to be able to be tested by
cd foo-x.y/src
./myprog
Unfortunately, it was keying off of the directory part o
Ralf Wildenhues wrote:
Hello Dan,
* Dan McMahill wrote on Mon, Mar 10, 2008 at 01:49:54PM CET:
I'm trying to debug a piece of open-source 3rd party software. It mixes
c++ and fortran and has a Makefile.am fragment that looks like:
foo_SOURCES= src/file1.cpp src/file2.cpp src/file3.
Hello,
I'm trying to debug a piece of open-source 3rd party software. It mixes
c++ and fortran and has a Makefile.am fragment that looks like:
foo_SOURCES= src/file1.cpp src/file2.cpp src/file3.F src/file4.F
The c++ parts compile file but then make dies with a complaint about no
rule for t
I have a program which as part of its build generates a large directory
structure that is a couple of levels deep and has a couple of thousand
ascii data files that the program may make use of at run time.
I'm wondering what the right way is to get this installed by automake.
Also I'm debating
Ralf Wildenhues wrote:
Hello Dan,
Now the problem is that the link order needs to be
src1.o src2.o src3.o src4.o src5.o
Just curious: what's the reason for the ordering constraint?
When static objects use inheritance, the base class must be initialized
before anything can be derived
Hello,
I'm having some problems with getting the correct link order using automake.
I have something like:
foo_SOURCES= src1.cc src4.cc src5.cc
nodist_foo_SOURCES= src2.cc src3.cc
and some extra suffix rules that specify how src2.cc and src3.cc are
created (they are generated at build time).
Akim Demaille wrote:
What would be the cleanest means to handle this exception?
Here is what I did:
- Force automake to generate an object specific rule by
using some foo_CXXFLAGS
- Open Makefile.in, get the specific rules.
- Use LTCOMPILECXX to factor the common part
- Append $(MY_NOPTION_C
Anyone else run into problems like the one described in #486?
Short summary is if you have texinfo documentation where the .info file
gets out of date because of additional files used in the texinfo sources
that 'distcheck' fails because the target tries to write to the (write
protected) sourc
Alexandre Duret-Lutz wrote:
"DM" == Dan McMahill <[EMAIL PROTECTED]> writes:
DM> Whats happening is that there are some dependencies for the docs
DM> which get created at build time which makes the .info files be out of date.
DM> Would it be reasonable then t
Ralf Wildenhues wrote:
Hi Dan,
* Dan McMahill wrote on Fri, Mar 24, 2006 at 02:57:15PM CET:
I'm using automake-1.9.6 and am having problems with texinfo files and a
read only source tree. In my generated Makefile.in, there is the
following suffix rule:
*snip*
Of particular intere
I'm using automake-1.9.6 and am having problems with texinfo files and a
read only source tree. In my generated Makefile.in, there is the
following suffix rule:
.texi.info:
restore=: && backupdir="$(am__leading_dot)am" && \
am__cwd=`pwd` && cd $(srcdir) && \
rm -rf $$backupdir &
On Thu, Oct 21, 2004 at 01:23:44AM -0400, Dan McMahill wrote:
>
> html_docs= ${info_TEXINFOS:.texi=.html}
> ps_docs=${info_TEXINFOS:.texi=.ps}
> pdf_docs= ${info_TEXINFOS:.texi=.pdf}
>
> I had some other stuff to, but I've stripped it down to only have
On Thu, Oct 21, 2004 at 01:32:29PM +0900, Andre Caldas wrote:
> Hello, Dan!
>
> Sorry for the last "wrong" advice.
>
> I've been searching, and I think that maybe you should not use
> EXTRA_DIST. I guess EXTRA_DIST is for files that "are not covered in the
> automatic rules".
>
> I guess you s
On Wed, Oct 20, 2004 at 10:00:31AM +0900, Andre Caldas wrote:
> Hi Dan,
>
> >I end up with foo.{ps,pdf,html} in the distfile, but if a user
> >runs 'make clean', then those files get removed. Now if they
> >don't have TeX installed, they can't rebuild them.
>
> Did you try DISTCLEANFILES or MAIN
I'd like to be able to include the .pdf, .ps, and .html format manuals
in my distfile and not have 'make clean' cause them to be rebuilt. The
manual source is foo.texi. I've added
info_TEXINFOS= foo.texi
pkgdata_DATA= ${html_docs} ${ps_docs} ${pdf_docs}
html_docs= ${info_TEXINFOS:.texi
Hi,
I'm working on converting a program over to use autoconf/automake for the build system.
The last problem I'm working on is that the original sources used the -Pfoo flag to
flex
and -p foo flag to bison. This has the effect of having flex produce 'lex.foo.c'
instead
of 'lex.yy.c' which seem
I hope this isn't a FAQ, but I didn't find anything in the mailing lists.
I have some code which is seperated into several subdirectories. I dont
want to have it compile to a convenience library and then link each one in.
So my question is whats the right way to list foo_SOURCES. Should it be l
17 matches
Mail list logo
