Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Right-click on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
|
From: Benjamin Kirk <benjamin.kirk@na...> - 2007-10-24 19:11:43
|
I've started a libmesh_tests tree to hold unit tests: http://libmesh.sourceforge.net/installation.php#test Check it out and let me know what you think. All that is there now is a infrastructure to build and run simple tests. Of course, this should be 'driven' by some smart script which runs the test and accepts/rejects the output. I've held back on that, though. I'm sure we should use something stronger than bash to handle that... -Ben |
|
From: Benjamin Kirk <benjamin.kirk@na...> - 2007-10-24 19:11:43
|
I've started a libmesh_tests tree to hold unit tests: http://libmesh.sourceforge.net/installation.php#test Check it out and let me know what you think. All that is there now is a infrastructure to build and run simple tests. Of course, this should be 'driven' by some smart script which runs the test and accepts/rejects the output. I've held back on that, though. I'm sure we should use something stronger than bash to handle that... -Ben |
|
From: Roy Stogner <roystgnr@ic...> - 2007-10-24 19:21:45
|
On Wed, 24 Oct 2007, Benjamin Kirk wrote: > I've started a libmesh_tests tree to hold unit tests: > > http://libmesh.sourceforge.net/installation.php#test > > Check it out and let me know what you think. All that is there now is a > infrastructure to build and run simple tests. Of course, this should be > 'driven' by some smart script which runs the test and accepts/rejects the > output. I've held back on that, though. I'm sure we should use something > stronger than bash to handle that... Last time I looked there weren't any public unit testing frameworks that I liked, but that was quite a while ago and if we found something good now it might be preferable to "rolling our own". If we do write our own test-running script, I remain a big fan of "make". Derek was wowed by how useful my LaTeX Makefile template was for papers with tons of figure format conversions, and that's a harder problem than unit testing. We'll want to use Make.common to build each test in the first place, and at that point we might as well use make for the whole thing, with a few common rules to do things like diffing filtered program output against a "gold standard", creating a "testname-success" or "testname-failure" file for each test, and maybe writing up some nice HTML output after the lot of the tests are finished. --- Roy |
|
From: John Peterson <peterson@cf...> - 2007-10-24 20:29:06
|
Can we standardize on an environment variable name for libmesh's directory? I've been using $LIBMESH_DIR (in the spirit of PETSc) for some time, it looks like you may prefer $LIBMESH_ROOT? Most of Roy's Makefiles seem to go for "../.." ;-) Whatever we decide to choose, we should try to be consistent in all our Makefiles from here on out... -John Benjamin Kirk writes: > I've started a libmesh_tests tree to hold unit tests: > > http://libmesh.sourceforge.net/installation.php#test > > Check it out and let me know what you think. All that is there now is a > infrastructure to build and run simple tests. Of course, this should be > 'driven' by some smart script which runs the test and accepts/rejects the > output. I've held back on that, though. I'm sure we should use something > stronger than bash to handle that... > > -Ben |
|
From: Martin Lüthi <luethi@va...> - 2007-10-24 20:40:46
|
Hi John Peterson writes: > Can we standardize on an environment variable name for libmesh's > directory? I've been using $LIBMESH_DIR (in the spirit of PETSc) > for some time, it looks like you may prefer $LIBMESH_ROOT? Most > of Roy's Makefiles seem to go for "../.." ;-) Something like $LIBMESH or $LIBMESH_ROOT would be fine. This makes it easier to copy the examples somewhere and play with them. My 0.02 Martin |
|
From: Roy Stogner <roystgnr@ic...> - 2007-10-24 21:00:18
|
On Wed, 24 Oct 2007, Martin Lthi wrote: > > Can we standardize on an environment variable name for libmesh's > > directory? I've been using $LIBMESH_DIR (in the spirit of PETSc) > > for some time, it looks like you may prefer $LIBMESH_ROOT? Most > > of Roy's Makefiles seem to go for "../.." ;-) > > Something like $LIBMESH or $LIBMESH_ROOT would be fine. This makes it > easier to copy the examples somewhere and play with them. The reason I use relative rather than absolute paths is because that makes it easier for me to jump between multiple different libMesh trees. Testing code with various combinations of configuration options (e.g. --enable-complex, --enable-amr, --enable-parmesh) turned on is easier when all you have to do is change directories and copy over the new versions of files to test. I'm fine with using a standard environment variable name (preferably $LIBMESH_ROOT), so long as we have a script in bin/ to set that variable to bin/.. (except, you know, smarter) so that it's easy to change on the fly. Alternatively, we could put this information (and much of Make.common) into a libmesh-config script, the way dozens of other packages do. Just talking crazy, there. I reserve the right to be sarcastic about our build system without inadvertently volunteering to do any work to improve it. --- Roy |
|
From: Benjamin Kirk <benjamin.kirk@na...> - 2007-10-24 21:05:34
|
> Alternatively, we could put this information (and much of Make.common) > into a libmesh-config script, the way dozens of other packages do. > > Just talking crazy, there. I reserve the right to be sarcastic about > our build system without inadvertently volunteering to do any work to > improve it. While some criticism of the build system is well-founded, this one is not ;-) ./contrib/bin/libmesh-config Does (almost) exactly that. It just needs an option --libmesh-install-dir or similar to return the directory. Note that in this case if libmesh-config is in your path that should be all you need. |
|
From: Roy Stogner <roystgnr@ic...> - 2007-10-24 21:17:40
|
On Wed, 24 Oct 2007, Benjamin Kirk wrote: > While some criticism of the build system is well-founded, this one is not > ;-) > > ./contrib/bin/libmesh-config Ah. Well, I'll just shut up then. I should have thought to check contrib/bin/, not just bin/. It looks like we're just hard coding `pwd` from the ./configure run to let libmesh-config find Makefile/Make.common at the moment. I presume Ondrej has added some hacks to make that work better on Debian? Distributions tend to frown on applications not being installable in locations other than their build directory. --- Roy |
|
From: Ondrej Certik <ondrej@ce...> - 2007-10-25 00:41:42
|
> It looks like we're just hard coding `pwd` from the ./configure run to
> let libmesh-config find Makefile/Make.common at the moment. I presume
> Ondrej has added some hacks to make that work better on Debian?
> Distributions tend to frown on applications not being installable in
> locations other than their build directory.
I didn't yet find time to try the new version. For the 0.6.0~rc2 I
used these "hacks":
cp /usr/share/misc/config.guess .
cp /usr/share/misc/config.sub .
PETSC_DIR=/usr/lib/petsc PETSC_ARCH=linux-gnu-c-opt
LDFLAGS=-Wl,-soname,libmesh.so.$(LIBMESH_VERSION),-lpetsc,-lpetscdm,-lpetscksp,-lpetscmat,-lpetscsnes,-lpetscts,-lpetscvec
./configure --host=$(DEB_HOST_GNU_TYPE) --build=$(DEB_BUILD_GNU_TYPE)
--prefix=/usr --mandir=\$${prefix}/share/man
--infodir=\$${prefix}/share/info --disable-laspack --disable-slepc
--disable-sfc --disable-gzstreams --disable-tecplot --disable-metis
--disable-parmetis --disable-tetgen --disable-triangle
mkdir -p $(meshbin)/usr/lib
mkdir -p $(meshdev)/usr/lib
libdir=`grep "hosttype " Make.common | cut -d "=" -f 2 | cut -c 2-`; \
cp lib/$${libdir}_opt/libmesh.so
$(meshbin)/usr/lib/libmesh.so.$(LIBMESH_VERSION)
ln -s /usr/lib/libmesh.so.$(LIBMESH_VERSION) $(meshdev)/usr/lib/libmesh.so
mkdir -p $(meshdev)/usr/include/libmesh
cp include/base/* include/enums/* include/fe/* include/geom/*
include/mesh/* include/numerics/* include/partitioning/*
include/quadrature/* include/solvers/* include/utils/*
$(meshdev)/usr/include/libmesh
rm $(meshdev)/usr/include/libmesh/libmesh_config.h.in
rm $(meshdev)/usr/include/libmesh/libmesh_contrib_config.h.in
#install the libmesh-pure
$(MAKE) distclean
rm -f config.sub config.guess
cp /usr/share/misc/config.guess .
cp /usr/share/misc/config.sub .
PETSC_DIR=/usr/lib/petsc PETSC_ARCH=linux-gnu-c-opt
LDFLAGS=-Wl,-soname,libmesh.so.$(LIBMESH_VERSION)-pure ./configure
--host=$(DEB_HOST_GNU_TYPE) --build=$(DEB_BUILD_GNU_TYPE)
--prefix=/usr --mandir=\$${prefix}/share/man
--infodir=\$${prefix}/share/info --disable-petsc --disable-mpi
--enable-laspack --disable-slepc --disable-sfc --disable-gzstreams
--disable-tecplot --disable-metis --disable-parmetis --disable-tetgen
--disable-triangle
$(MAKE)
mkdir -p $(meshbinpure)/usr/lib
mkdir -p $(meshdevpure)/usr/lib
libdir=`grep "hosttype " Make.common | cut -d "=" -f 2 | cut -c 2-`; \
cp lib/$${libdir}_opt/libmesh.so
$(meshbinpure)/usr/lib/libmesh.so.$(LIBMESH_VERSION)-pure
ln -s /usr/lib/libmesh.so.$(LIBMESH_VERSION)-pure
$(meshdevpure)/usr/lib/libmesh.so
mkdir -p $(meshdevpure)/usr/include/libmesh
cp include/base/* include/enums/* include/fe/* include/geom/*
include/mesh/* include/numerics/* include/partitioning/*
include/quadrature/* include/solvers/* include/utils/*
$(meshdevpure)/usr/include/libmesh
rm $(meshdevpure)/usr/include/libmesh/libmesh_config.h.in
rm $(meshdevpure)/usr/include/libmesh/libmesh_contrib_config.h.in
It fixes the SONAME bug, put the header files the correct locations,
removes some left overs (*.in files) etc. After this, the package
conforms to quite strict Debian policy and everything is fine.
Ondrej
|
|
From: John Peterson <peterson@cf...> - 2007-10-24 21:08:26
|
Roy Stogner writes: > On Wed, 24 Oct 2007, Martin Lthi wrote: > > > > Can we standardize on an environment variable name for libmesh's > > > directory? I've been using $LIBMESH_DIR (in the spirit of PETSc) > > > for some time, it looks like you may prefer $LIBMESH_ROOT? Most > > > of Roy's Makefiles seem to go for "../.." ;-) > > > > Something like $LIBMESH or $LIBMESH_ROOT would be fine. This makes it > > easier to copy the examples somewhere and play with them. > > The reason I use relative rather than absolute paths is because that > makes it easier for me to jump between multiple different libMesh > trees. Testing code with various combinations of configuration > options (e.g. --enable-complex, --enable-amr, --enable-parmesh) turned > on is easier when all you have to do is change directories and copy > over the new versions of files to test. Excellent point. Just shows that I don't do enough testing with various options enabled. > I'm fine with using a standard environment variable name (preferably > $LIBMESH_ROOT), so long as we have a script in bin/ to set that > variable to bin/.. (except, you know, smarter) so that it's easy to > change on the fly. It's settled for me then, LIBMESH_ROOT shall be the blessed installed location of libmesh. > Alternatively, we could put this information (and much of Make.common) > into a libmesh-config script, the way dozens of other packages do. Right, you mean like contrib/bin/libmesh-config ? Since we can't put it in /usr/bin, we still need to know a LIBMESH_ROOT to get to this script. -J |
Sign up for the SourceForge newsletter:
No, thanks