Re: Reducing verbosity of automake

I wrote: > > It might be a nice feature to add this to the autotools, but is it > > really necessary? Why not follow the unix philosophy and write your > > own filter (using sed, python, perl, whatever) that reduces the > > verbose lines you don't want into something more managable? [EMAIL PROTECT

Re: Reducing verbosity of automake

Brendon Costa <[EMAIL PROTECTED]> wrote: > ... > When compiling a project using: autoconf/automake/libtool, there is just > too much data being output to the screen when i run the make command. In > the jam system i am porting over if I was to issue the jam command, it > would print messages like:

Re: How to use BUILT_SOURCES in non-recursive, multi-directory project?

I wrote: >> .fl.h: >> d=`dirname [EMAIL PROTECTED] ; \ >> f=`basename $@ .h`.fl ; \ >> cp $< $(top_builddir)/$$d/$$f ; \ >> cd $(top_builddir)/$$d ; \ >> fluid -c $$f >> >> BUILT_SOURCES += src/foo.h Ralf replied: > dirname and ba

Re: Adding BUILT_SOURCES to a multi-directory, non-recursive project

Alexandre Duret-Lutz <[EMAIL PROTECTED]> wrote: > lots of helpful things... Thanks. I will look into your suggestions this evening. No doubt you have noticed that I reposted a more up to date version of src/Makefile.am that does handle some of these problems better, and I have made even further p

How to use BUILT_SOURCES in non-recursive, multi-directory project?

I've been trying to set up a multi-directory project using non-recursive auto{conf,make} to build an FLTK application (see http://www.fltk.org). I have created a simple example for testing, where I have a sub-directory containing foo.fl and foo_test.cxx, and what I need to do is: use 'fluid -c

Adding BUILT_SOURCES to a multi-directory, non-recursive project

I was given help two weeks ago in the thread "Autoconfisticating a multi-directory, non-recursive, GNU-make specific project" (see http://lists.gnu.org/archive/html/automake/2006-02/msg00036.html) Three years ago on this list, I was helped with BUILT_SOURCES in the thread "How to specify 2 stage

Re: Autoconfisticating a multi-directory, non-recursive, GNU-make specific project

Ralf Wildenhues kindly provided me with 4 out of the 5 critical pieces of information that I needed: > --- configure.ac --- > AM_INIT_AUTOMAKE([1.9 subdir-objects]) 1. subdir-objects to build x/y/z.o from x/y/z.c instead of just z.o see the last paragraph describing 'maude_SOURCES' in the manu

Autoconfisticating a multi-directory, non-recursive, GNU-make specific project

I've always struggled with auto{conf,make} in the past, but decided that my next project really needs to have some chance of portability. I'm aware of the famous "Recursive Make Considered Harmful" paper. (see http://www.pcug.org.au/~millerp/rmch/recu-make-cons-harm.html) Searching back through t

Re: Fwd: Automake 1.7.1b prerelease available (beta for Automake 1.7.2)

[EMAIL PROTECTED] said: > The following prerelease includes fixes for bugs you reported or > fixed. Could you verify it works? > Bugs fixed in 1.7.1b: > ... > * Recognize multiple inference rules such as `.a.b .c.d:'. (PR/371) I assume that this relates to the question reported to the automake

Re: How to specify 2 stage build in Makefile.am

Apologies for not replying sooner, but I've been away for a week. Duncan Gibson wrote: DG> bin_PROGRAMS = CubeView DG> DG> CubeView_SOURCES = \ DG> CubeMain.cxx \ DG> CubeView.cxx CubeView.h \ DG> CubeViewUI.fl DG> DG> SUFFIXES = .cxx .h .fl DG> DG>