Re: split check target into check and test targets

2010-02-23 Thread Bob Friesenhahn

On Tue, 23 Feb 2010, 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 check_PROGRAMS and still use the 
generated parallel-tests using TESTS?  Thanks.


You are trying to do something which violates the GNU coding 
standards since 'check' has a standard definition.


If you use a different target name then there should be no problem:

checkprogs : check_PROGRAMS

test : check

Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/




Re: split check target into check and test targets

2010-02-24 Thread Baurzhan Ismagulov
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 check_PROGRAMS and still use the generated
> parallel-tests using TESTS? Thanks.

There are also these ways:
http://www.opensubscriber.com/message/automake@gnu.org/2136673.html

With kind regards,
-- 
Baurzhan Ismagulov
http://www.kz-easy.com/




RE: split check target into check and test targets

2010-02-24 Thread Daily, Jeff A
> > 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-tests using TESTS?  Thanks.
> 
> You are trying to do something which violates the GNU coding
> standards since 'check' has a standard definition.
> 
> 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?  Hopefully there's a more or less automatic way using 
automake.  I have quite a few subdirectories each with a few test program 
directories so it would be tedious to make this change.  Is there some way to 
tap into the RECURSIVE_TARGETS variable?

Thanks,

Jeff




Re: split check target into check and test targets

2010-02-24 Thread John Calcote

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 might I split the building
and running of check_PROGRAMS and still use the generated
parallel-tests using TESTS? Thanks.
 

There are also these ways:
http://www.opensubscriber.com/message/automake@gnu.org/2136673.html
   


Additionally, if I want to build a particular check program (perhaps as 
I'm working out the compiler errors, but before I'm ready to actually 
run the tests), I just type "make " from that 
directory. Alexander's solution is great, though. I'm going to use that 
one myself.


Regards,
John




Re: split check target into check and test targets

2010-02-24 Thread Ralf Wildenhues
* 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?  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 file and include that in the
other Makefile.am files.

I'd like to improve this situation at some point.

Cheers,
Ralf




RE: split check target into check and test targets

2010-02-24 Thread Daily, Jeff 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 file and include that in
> the
> other Makefile.am files.
> 
> I'd like to improve this situation at some point.
> 
> Cheers,
> Ralf

Good advice, Ralf.  I've done just that.  Now I have the freedom to add any 
recursive targets I need.

I used find with sed to insert into the top of all of my Makefile.am files:

find -name 'Makefile.am' -exec sed -i '1i\include 
$(top_srcdir)/config/ga_recur.mk\n' {} \;

All I need to do is add a few lines to my ga_recur.mk to add additional 
recursive targets, if I ever need them.  I could probably have removed the -am 
target stuff, right?  Oh, well.  There were only a handful of Makefile.am files 
which had a check_PROGRAMS target, so in those files I've added:

TESTS = $(check_PROGRAMS)
checkprogs:
$(MAKE) $(AM_MAKEFLAGS) $(check_PROGRAMS)

The contents of ga_recur.mk are:

# COPIED FROM MAKEFILE GENERATED BY AUTOMAKE 1.11.1
# 
# Modified to use our own recursive targets.
#
# This directory's subdirectories are mostly independent; you can cd
# into them and run `make' without going through this Makefile.
# To change the values of `make' variables: instead of editing Makefiles,
# (1) if the variable is set in `config.status', edit `config.status'
# (which will cause the Makefiles to be regenerated when you run `make');
# (2) otherwise, pass the desired values on the `make' command line.
$(GA_RECURSIVE_TARGETS):
@fail= failcom='exit 1'; \
for f in x $$MAKEFLAGS; do \
  case $$f in \
*=* | --[!k]*);; \
*k*) failcom='fail=yes';; \
  esac; \
done; \
dot_seen=no; \
target=`echo $@ | sed s/-recursive//`; \
list='$(SUBDIRS)'; for subdir in $$list; do \
  echo "Making $$target in $$subdir"; \
  if test "$$subdir" = "."; then \
dot_seen=yes; \
local_target="$$target-am"; \
  else \
local_target="$$target"; \
  fi; \
  ($(am__cd) $$subdir && $(MAKE) $(AM_MAKEFLAGS) $$local_target) \
  || eval $$failcom; \
done; \
if test "$$dot_seen" = "no"; then \
  $(MAKE) $(AM_MAKEFLAGS) "$$target-am" || exit 1; \
fi; test -z "$$fail"
# END COPY

GA_RECURSIVE_TARGETS = checkprogs-recursive

checkprogs: checkprogs-recursive
checkprogs-am:




Re: split check target into check and test targets

2010-02-24 Thread Ralf Wildenhues
* 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/automake@gnu.org/2136673.html
> 
> Additionally, if I want to build a particular check program (perhaps
> as I'm working out the compiler errors, but before I'm ready to
> actually run the tests), I just type "make "
> from that directory. Alexander's solution is great, though. I'm
> going to use that one myself.

Actually.  I think I should write some more on this, and recommend y'all
rethink.  :-)

Dunno if you've heard of the parallel-tests option (enabling a newer
testsuite driver), but if you haven't, then read


It allows to run tests in parallel (hence the name), but it also allows
interleaving of test program building and test running (a feature that
was IIRC the main motivation for Akim to develop this driver).  It also
allows you to sort of rerun only tests that are out of date (once you
have formulated dependencies for not only test programs, but also test
results).  The way to get interleaved test program building and
execution is to use EXTRA_PROGRAMS instead of check_PROGRAMS (see the
manual), which is nice if you have only a couple of those that need
updating, and building is not a lot faster/slower than test execution.

One other note I think is in place is that one can change check_PROGRAMS
to noinst_PROGRAMS to have them built with 'make all' already (gnulib
encourages this, for example, in order to see build failures at 'all'
time already.  This sort of goes in the other direction, away from
"rebuild as lazily as possible, for more parallelism" but can be very
useful as well (and with lots of test programs, allows a lot of
parallelism too).

Hope that helps.  If you have any questions feel free to ask.

Cheers,
Ralf




Re: split check target into check and test targets

2010-02-24 Thread Daily, Jeff A
>  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_PROGRAMS from within the same 
directory.  But what I needed was a new recursive target to build the 
check_PROGRAMS throughout my build tree.  I've posted my solution elsewhere in 
this thread, but I just realized I missed the use .PHONY there.  Thanks.

Jeff



Re: split check target into check and test targets

2010-02-24 Thread Baurzhan Ismagulov
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 dependencies for not only test programs, but
> also test results)

Can't automake do the former automatically? Could you give an example
use case for the latter?


With kind regards,
-- 
Baurzhan Ismagulov
http://www.kz-easy.com/




Re: split check target into check and test targets

2010-03-02 Thread Steffen Dettmer
On Wed, Feb 24, 2010 at 7:17 PM, John Calcote  wrote:
> Alexander's solution is great, though. I'm going to use that one myself.

For this, you'd need to change all Makefile.ams and it isn't working
recursively...

What is with having

  AC_SUBST(TESTS)

in configure.in and running:

  $ make check TESTS=

to skip test execution?

> Additionally, if I want to build a particular check program (perhaps as I'm
> working out the compiler errors, but before I'm ready to actually run the
> tests), I just type "make " from that directory.

You just have to remember to add `.exe' on cygwin and MSYS,
especially within scripts / make rules ($(EXEEXT)),
otherwise (at least GNU-) make uses a default built-in rule
to compile and link , typically with
different LIBS. The compiler command line looks plausible but
fails and confuses people :-)

oki,

Steffen




Re: split check target into check and test targets

2010-03-02 Thread Ralf Wildenhues
Hello,

* Steffen Dettmer wrote on Tue, Mar 02, 2010 at 11:00:39AM CET:
> On Wed, Feb 24, 2010 at 7:17 PM, John Calcote wrote:
> > Alexander's solution is great, though. I'm going to use that one myself.
> 
> For this, you'd need to change all Makefile.ams and it isn't working
> recursively...

Yes.

> What is with having
> 
>   AC_SUBST(TESTS)
> 
> in configure.in and running:
> 
>   $ make check TESTS=
> 
> to skip test execution?

I don't see why you need the AC_SUBST in order to be able to do the
second line.  In fact, it is typically harmful because when not used,
automake mangles the TESTS variable nicely for you, adding $(EXEEXT)
where needed and so on.  You have to do that yourself in configure.

> > Additionally, if I want to build a particular check program (perhaps as I'm
> > working out the compiler errors, but before I'm ready to actually run the
> > tests), I just type "make " from that directory.
> 
> You just have to remember to add `.exe' on cygwin and MSYS,
> especially within scripts / make rules ($(EXEEXT)),
> otherwise (at least GNU-) make uses a default built-in rule
> to compile and link , typically with
> different LIBS. The compiler command line looks plausible but
> fails and confuses people :-)

That, too.

Cheers,
Ralf