lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Dependent files for 'make check' [Was: Running unit tests in l


From: Vadim Zeitlin
Subject: Re: [lmi] Dependent files for 'make check' [Was: Running unit tests in less time]
Date: Mon, 8 May 2017 00:59:01 +0200

On Sun, 7 May 2017 22:47:14 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2017-05-06 22:22, Vadim Zeitlin wrote:
GC> > On Fri, 5 May 2017 22:31:09 +0000 Greg Chicares <address@hidden> wrote:
GC> >
GC> 
GC> [... unit tests depend on finding all these files
GC>   sample.ill
GC>   single_cell_document.xsd
GC> [both of which are in .git/../ ]
GC>   configurable_settings.xml
GC> and a set of product files in /opt/lmi/data/ ]
GC> 
GC> > GC> ...couldn't all those problems could be solved by installing lmi into
GC> > GC> '/opt/lmi/data'?
GC> > 
GC> >  They probably could, but especially under Linux it would be really nice 
if
GC> > the program could be tested without requiring root permissions, which are
GC> > normally necessary for installing it under /opt.
GC> 
GC> We could write copies (or symlinks) elsewhere. We already use
GC>   /etc/opt/lmi
GC> for other purposes. These files don't really belong there, though.
GC> What would be the most natural place? $HOME should be available, but
GC> doesn't seem appropriate. How about /var/lmi ?

 I'd rather use a subdirectory of the build directory, to keep things
self-contained.

GC> > But even leaving the permission issues aside, it's very unusual to
GC> > require installing before being able to run the tests. I.e. the
GC> > traditional workflow is "make && make check && make install".
GC> 
GC> Surely this sort of situation must have arisen with other projects;
GC> how do they handle it?

 I actually don't know, it would be interesting to find some GNU project
with the same problem and look at how it's dealt with in it. I can't find
anything right now, but I might search more if you think it can be useful.
For now I've just found out that automake does have "installcheck" target
which runs tests after installation too. But I think the fact that I had
never heard about it before shows that it's not very commonly used.

GC> The source directory .git/../ already contains two of the files
GC> mentioned above as well as
GC>   cgi.touchstone
GC> which is used by 'cgi_tests'; is it considered normal for 'make check'
GC> to copy such files from the source directory?

 I believe so, at least I don't see anything wrong with it.

GC> The most natural way to generate product files is to build and run
GC> 'product_files'. Is there a conventional way of handling that? It
GC> seems far better to run that program than to maintain repository
GC> copies of the files it creates.

 Definitely. With automake this could be done via check-local rule, which
is a hook for "make check". With manual makefiles we could just do the same
thing by simply making the unit test targets depend on these files and
providing rules for creating them using product_files, couldn't we?

GC> Then there's this file, created as a here-doc by 'install_msw.sh':
GC>   cat >/opt/lmi/data/configurable_settings.xml <<EOF
GC> Is there a convention for files like that?

 I think this one should be just a normal Makefile target too.

 Regards,
VZ


reply via email to

[Prev in Thread] Current Thread [Next in Thread]