Re: How to run TESTS automatically on each source code change?

2014-07-31 Thread Gavin Smith
On Thu, Jul 24, 2014 at 4:48 PM, Steffen Dettmer
steffen.dett...@gmail.com wrote:
 Hi,

 I have a test that generates a log file, which I can manually run via
 make check. Is there a simple way to automate that? For the moment I
 just created a pragmatic target autotest, but I think it is ugly
 (and too specific).

What do you want to happen? The test to be automatically run whenever
make is run?

 Any pointers appreciated!

 Regards,
 Steffen


 autotest:
 @echo Will run \`make check' after each change, stop with INT. ; \
 while true ; do \
   if ! make --question -s -j4 testrunner ; then \
 echo Rechecking... ; \
   make -s check || { \
 echo failed to run `date`  testrunner.log ; \
   } ; \
   fi ; \
   sleep 1 ; \
 done




Re: How to run TESTS automatically on each source code change?

2014-07-31 Thread Pippijn van Steenhoven
On Thu, Jul 24, 2014 at 4:48 PM, Steffen Dettmer steffen.dett...@gmail.com 
wrote:
 Hi,

 I have a test that generates a log file, which I can manually run via
 make check. Is there a simple way to automate that? For the moment I
 just created a pragmatic target autotest, but I think it is ugly
 (and too specific).

Hi,

You may want to look into inotify-tools, in particular inotifywait. You
can use it to monitor a list of files or optionally recursive directories
for changes and do something like:

  while true; do inotifywait file ...; make check; done

If the list of files is very large, the set-up can take a long time
(several seconds for tens of thousands of files). In that case, you may
want to write a smarter script with inotifywatch that has the set-up
cost only once, and then you just monitor inotifywatch's standard output.
If your list of files is extremely large, then you may run out of kernel
memory or the user limit on inotify watches. In the latter case, you can
increase the limit in /etc/sysctl.conf (the relevant variable is
fs.inotify.max_user_watches). In the former case, you really have a very
large file list and you may want to restrict it to your current working
set.

I hope this helps.

Pippijn


signature.asc
Description: Digital signature


Re: Automake 1.14 and subdir-objects

2014-07-31 Thread David Beer
Gavin,

Thanks for your reply. Here's a more specific breakdown of what the project
does:

src/a/Makefile.am:

a_SOURCES = bob.c tom.c

src/b/Makefile.am:

b_SOURCES = mary.c ../a/tom.c

The purpose was so that tom.c would be recompiled with a different
preprocessor switch. There were only a few files that failed for this case,
so I was able to work around this. The other case:

# this is a unit test directory for mary.c
src/b/mary/Makefile.am:

mary_SOURCES = test_mary.c ../../mary.c

We simply include this so that we don't have to have a copy of mary.c in
the unit test directory, but this now fails with a message like:

Makefile:738: ../../.deps/mary.Plo: No such file or directory
make[5]: *** No rule to make target `../../.deps/mary.Plo'.  Stop.

Upon looking in that directory, there is a mary.Po and not a mary.Plo. I
don't know why that is or what that means - I guess these specify
dependencies or something like that. In this case, we have a unit test
directory for each file in the project and duplicating every file in the
project seems undesirable. Prior to 1.14 I didn't have to set
subdir-objects for this to build, so it just worked and it set in the
Makefile.in files you'd see things like:

# prior
am_mary_la_OBJECTS = test_mary.o mary.o
mary_la_OBJECTS = test_mary.c ../../mary.c

# 1.14 with subdir-objects
am_mary_la_OBJECTS = test_mary.o ../../mary.o
mary_la_OBJECTS = test_mary.c ../../mary.c

Please let me know if there's any clarification I can provide, and once
again, I appreciate the help.



On Thu, Jul 31, 2014 at 4:05 AM, Gavin Smith gavinsmith0...@gmail.com
wrote:

 On Thu, Jul 24, 2014 at 9:09 PM, David Beer db...@adaptivecomputing.com
 wrote:
  All,
 
  I am currently trying to get our project completely compatible with
  automake 1.14. We have multiple places where we compile a source file
 from
  another of the project's subdirectories in a given subdirectory. The two
  main use cases are:
 
  1. To recompile a source file with different preprocessor variables
  2. To execute the unit tests (we use the check framework).
 
 Do you mean you are using the same subdirectory as the build directory
 for several different source directories (in a parallel build)? That
 sounds unusual. If you mean that you are running configure several
 times on the same source directory for different build directories (to
 test different variables, options), there won't be files from other
 builds in each build directory, and shouldn't have the problems you
 mentioned. Maybe if you described a simple project (e.g. show the
 contents of the files) that worked in earlier versions but not in
 automake 1.14, it would be easier to see if you were going about it in
 the right way.




-- 
David Beer | Senior Software Engineer
Adaptive Computing


Re: Automake 1.14 and subdir-objects

2014-07-31 Thread Gavin Smith
On Thu, Jul 31, 2014 at 9:32 PM, David Beer db...@adaptivecomputing.com wrote:
 Gavin,

 Thanks for your reply. Here's a more specific breakdown of what the project
 does:

 src/a/Makefile.am:

 a_SOURCES = bob.c tom.c

 src/b/Makefile.am:

 b_SOURCES = mary.c ../a/tom.c

 The purpose was so that tom.c would be recompiled with a different
 preprocessor switch. There were only a few files that failed for this case,
 so I was able to work around this. The other case:

It is clearer now what you are trying to do. It might be worth noting
that you can specify target-specific compliation flags with variables
like a_CPPFLAGS and b_CPPFLAGS: however, this would normally be done
when a and b were targets defined in the same Makefile.am. This would
lead the created object files to have different names, so might work
in your case, but I believe that this kind of sharing of source files
between Makefile.am's is not really supported. I imagine there could
be problems with e.g. dependency tracking. Maybe consider using a
non-recursive build system with a single Makefile.am if it is
appropriate for your project.

Another idea is to specify the files like tom.c in src/b/Makefile.am as

BUILT_SOURCES=tom.c

and then have a hand-written rule to copy the tom.c file into the
build directory for b, e.g.

tom.c:
cp $(top_builddir)/a/tom.c .

(I haven't tested this.)