Richard,
Why are all the header files from Projects/subA/ being enumerated in the
compile line? I think that's the problem.
H
On 02/25/2010 06:16 AM, rrlangly wrote:
Does anyone have an idea as to why I'd get the following error when compiling
my program using autotools. This used to compile and run, then I added new
code and linked against a new library, and now I get this.
g++ -DHAVE_CONFIG_H -I. -I../../GXT/src -I.
rrlangly writes:
> Does anyone have an idea as to why I'd get the following error when
> compiling my program using autotools. This used to compile and run, then
> I added new code and linked against a new library, and now I get this.
> g++ -DHAVE_CONFIG_H -I. -I../../GXT/src -I.. -I../../GXT/i
Does anyone have an idea as to why I'd get the following error when compiling
my program using autotools. This used to compile and run, then I added new
code and linked against a new library, and now I get this.
g++ -DHAVE_CONFIG_H -I. -I../../GXT/src -I.. -I../../GXT/include
-I/usr/include/glib
Ralf Wildenhues wrote:
The Automake documentation on the other hand states that I should put $(FLIBS)
into the apropriate _LDADD or _LIBADD variable. That would include the value
of FLIBS before the value of LIBS on the linker command line, contradicting
the autoconf documentation.
Is there a r
Ralf Wildenhues wrote:
The Automake documentation on the other hand states that I should put $(FLIBS)
into the apropriate _LDADD or _LIBADD variable. That would include the value
of FLIBS before the value of LIBS on the linker command line, contradicting
the autoconf documentation.
Is there a r
On Wed, Feb 24, 2010 at 08:49:26PM +0100, Ralf Wildenhues wrote:
> Dunno if you've heard of the parallel-tests option
...
> It also allows you to sort of rerun only tests that are out of date
Wow! Does it work with DejaGNU? Which automake version is required?
> (once you have formulated dependen
Hello Steven,
sorry to bother you. Jö asked this on the Automake mailing list:
* Jö Fahlke wrote on Tue, Feb 23, 2010 at 10:06:01AM CET:
> Our project uses C++, but some of its optional dependencies require linking
> with fortran libraries (like blas). What is the proper way to do this?
>
> On
> Just add your own rule that depends on $(check_PROGRAMS):
>
> .PHONY: check-norun
> check-norun: $(check_PROGRAMS)
>
> and type `make check-norun' instead of `make check'.
I copied the above from the link since I had trouble navigating to it.
This is a great solution for building the check_PRO
Hello Bill,
* Mi Yang (杨觅) wrote on Wed, Feb 24, 2010 at 03:34:26PM CET:
> I met a strange problem when "automake -a":
>
> core/Makefile.am:3: variable `main_SOURCES' is defined but no program or
> core/Makefile.am:3: library has `main' as canonical name (possible typo)
Well, it is meant as a he
* John Calcote wrote on Wed, Feb 24, 2010 at 07:17:08PM CET:
> On 2/24/2010 1:50 AM, Baurzhan Ismagulov wrote:
> >On Tue, Feb 23, 2010 at 04:05:47PM -0800, Daily, Jeff A wrote:
> >>I attempted to split the "make check" target into "make check" (build
[...]
> >http://www.opensubscriber.com/message/a
> > Ok, fair enough. But what's the easiest way to create a new
> recursive
> > target such as checkprogs? Hopefully there's a more or less
> automatic
> > way using automake.
>
> No, it's not, which is a real bummer. Best you can do is somehow copy
> the $(RECURSIVE_TARGETS) rule as a fragment
On Wed, Feb 24, 2010 at 2:23 PM, Ralf Wildenhues wrote:
> The above looks ok to me. Since I cannot, from your description,
> exactly reproduce the code that caused the warning for you, I cannot say
> whether that was a problem.
>
> The code as above does not yet take care of adjusting SUBDIRS (an
Hello,
* NightStrike wrote on Wed, Feb 24, 2010 at 06:29:04PM CET:
> AC_MSG_CHECKING([whether to build the optional libraries])
> AC_ARG_WITH([libraries],
> [AS_HELP_STRING([--with-libraries=ARG],
> [Build the extra mingw-w64 libs, where ARG is one of libmangle,
> pseh, or all])],
> [],
>
* Daily, Jeff A wrote on Wed, Feb 24, 2010 at 07:09:36PM CET:
> > If you use a different target name then there should be no problem:
> >
> > checkprogs : check_PROGRAMS
> >
> > test : check
> Ok, fair enough. But what's the easiest way to create a new recursive
> target such as checkprogs? Ho
On 2/24/2010 1:50 AM, Baurzhan Ismagulov wrote:
On Tue, Feb 23, 2010 at 04:05:47PM -0800, Daily, Jeff A wrote:
I attempted to split the "make check" target into "make check" (build
check_PROGRAMS) and "make test" (run check_PROGRAMS). However, I get
warnings that check-am was overridden. How
> > I attempted to split the "make check" target into "make check"
> > (build check_PROGRAMS) and "make test" (run check_PROGRAMS).
> > However, I get warnings that check-am was overridden. How might I
> > split the building and running of check_PROGRAMS and still use the
> > generated parallel-te
I'm sending this to both lists because I don't know which one is
right. I'm trying to conditionally configure and build subdirectories
using Automake conditionals. I'm flipping back and forth between both
manuals, so I'm guessing both apply.
I have a top level configure/makefile that I'm buildin
Hi,
Andreas Jellinghaus wrote:
Hi,
the combination autoconf/automake/libtool
makes it quite easy to create shared libraries.
but how can I install the file created as a single *.so
file, but without any *.la file etc.
the shared libraries we create implement a fixed plugin
interface thus they
Hi,
the combination autoconf/automake/libtool
makes it quite easy to create shared libraries.
but how can I install the file created as a single *.so
file, but without any *.la file etc.
the shared libraries we create implement a fixed plugin
interface thus they don't need the normal versioning
s
Hi!
Our project uses C++, but some of its optional dependencies require linking
with fortran libraries (like blas). What is the proper way to do this?
On the one hand the Autoconf documentation says that the output variable FLIBS
should be included after LIBS when linking. This is consistent wi
Hi guys,
I met a strange problem when "automake -a":
core/Makefile.am:3: variable `main_SOURCES' is defined but no program or
core/Makefile.am:3: library has `main' as canonical name (possible typo)
It happens only when generate executable files, as long as I choose to
generate .so lib files, ev
On Tue, Feb 23, 2010 at 04:05:47PM -0800, Daily, Jeff A wrote:
> I attempted to split the "make check" target into "make check" (build
> check_PROGRAMS) and "make test" (run check_PROGRAMS). However, I get
> warnings that check-am was overridden. How might I split the building
> and running of chec
23 matches
Mail list logo
