Re: How to run TESTS automatically on each source code change?
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?
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
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
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.)
