Oh ok, what it should do is importantly add -I/path/to/libmesh/include/libmesh,
So everything will resolve without being prefixed.
I know that works with the pkg-config option and libmesh-config option - ill
double check Make.common when I get in.
On Nov 18, 2012, at 11:20 PM, "Derek Gaston"
Hi,
I did a clean checkout (r6404), ran ./configure and make throws this
errors:
$ make
CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh
/home//opt/build/libmesh-autotools/libmesh/build-aux/missing --run
aclocal-1.12 -I m4
/home//opt/build/libmesh-autotools/libmesh/build-aux/missing: line
>
>
> What do I have to do, to get a successful build?
>
> Robert
>
Hi Robert -
Will you please try
$ svn revert -R .
$ ./configure --disable-maintainer-mode --prefiix=…
$ make && make install
And let me know what that does?
I'll update the checked in configure script to have maintainer mo
Hi Ben,
make starts to compile the first few contrib-packages fine, but fails on
parmetis:
make[1]: Entering directory
`/home//opt/build/libmesh-autotools/libmesh/contrib/parmetis'
CC Lib/akwayfm.lo
In file included from ./Lib/parmetislib.h:21:0,
from Lib/akwayfm.c:
On Nov 19, 2012, at 8:39 AM, Robert wrote:
> My older installation of libmesh (r5498) works fine on the same computer with
> MPI. Even with
> "make V=0" I could not get more information about the compilerflags used, so
> I cannot really
> figure out, if it is a problem on my side or the build-
Very good, thanks. Where on your system is MPI actually installed?
The issue is that the Parmetis makefile is not inheriting every -I…. that
libMesh is using, which is actually the way I want it. In particular, it is
not getting all of libmesh_optional_INCLUDES
But the only thing I suspect t
Hi Ben,
I am using the mpi installation provided by PetSc with
--download-mpich=1. So the mpi used should be the one in
~/opt/build/petsc-3.2-p6/linux-gnu-opt/include
Robert
On Mon, Nov 19, 2012 at 09:28:22AM -0600, Kirk, Benjamin (JSC-EG311) wrote:
> Very good, thanks. Where on your system is
On Nov 19, 2012, at 10:07 AM, Robert wrote:
> Hi Ben,
>
> I am using the mpi installation provided by PetSc with
> --download-mpich=1. So the mpi used should be the one in
> ~/opt/build/petsc-3.2-p6/linux-gnu-opt/include
OK, I'll see about building PETSC like this and update the configure scrip
Make that --disable-parmetis - Looks like nemesis does not actually use MPI?!
-Ben
On Nov 19, 2012, at 10:20 AM, "Kirk, Benjamin (JSC-EG311)"
wrote:
> On Nov 19, 2012, at 10:07 AM, Robert wrote:
>
>> Hi Ben,
>>
>> I am using the mpi installation provided by PetSc with
>> --download-mpich=1
On Nov 19, 2012, at 10:07 AM, Robert wrote:
> Hi Ben,
>
> I am using the mpi installation provided by PetSc with
> --download-mpich=1. So the mpi used should be the one in
> ~/opt/build/petsc-3.2-p6/linux-gnu-opt/include
r6407 should pass PETSc's include paths to parmetis, which should resolve
On Sat, 17 Nov 2012, Kirk, Benjamin (JSC-EG311) wrote:
> Then I'll add the generated files.
Thanks for this.
We probably ought to make "autogenerating nightly 'make dist'
tarballs" a higher priority than I'd anticipated, though. I did a
"bootstrap" to make sure that still worked, and now my "s
On Nov 19, 2012, at 11:06 AM, Roy Stogner wrote:
> We probably ought to make "autogenerating nightly 'make dist'
> tarballs" a higher priority than I'd anticipated, though. I did a
> "bootstrap" to make sure that still worked, and now my "svn stat" is
> littered with dozens of modified .in files
On Mon, 19 Nov 2012, Kirk, Benjamin (JSC-EG311) wrote:
Yup, working on it now. for obvious reasons I don't want to add
them to the repository, so I'm looking for a source forge/github
file upload space we can use…
Why not just add them to the same SourceForge file releases page as
the real
On Fri, 16 Nov 2012, Kirk, Benjamin (JSC-EG311) wrote:
> In the meantime please contact me before you get too frustrated with
> automake - it is usually easy to do something if you do it the
> 'automake way.'
As long as we're dogpiling you with bug reports:
There was a small issue with trilino
On Nov 19, 2012, at 11:32 AM, Roy Stogner wrote:
>
> On Fri, 16 Nov 2012, Kirk, Benjamin (JSC-EG311) wrote:
>
>> In the meantime please contact me before you get too frustrated with
>> automake - it is usually easy to do something if you do it the
>> 'automake way.'
>
> As long as we're dogpi
On Mon, 19 Nov 2012, Kirk, Benjamin (JSC-EG311) wrote:
> Is this a clean trunk or updated on top of an old one?
On top of an old one; but since that's going to be a common problem I
updated the Makefile.am to (in theory and in my experiments, at least)
remove any .inc files that happened to be p
On Mon, Nov 19, 2012 at 1:08 PM, Roy Stogner wrote:
> As long as I'm pestering you about the new system: how do we rebuild a
> single example now without re-running a full "make check"? Just
> running "make" in the directory of an example that had had its library
> changed out from under it claim
On Nov 19, 2012, at 2:08 PM, Roy Stogner wrote:
> As long as I'm pestering you about the new system: how do we rebuild a
> single example now without re-running a full "make check"? Just
> running "make" in the directory of an example that had had its library
> changed out from under it claimed
On Nov 19, 2012, at 2:10 PM, John Peterson wrote:
>
> Try 'make run'.
>
> While we're on the subject. Should/do the examples get installed anywhere
> when you do make install.?
the sources for all the examples get installed in nice little standalone
directories, but the binaries themselves
On Mon, 19 Nov 2012, Kirk, Benjamin (JSC-EG311) wrote:
Paul and I have been back and forth on installing the example
binaries - if you think it is important I could do it…
I'd vote "no" but wouldn't be bothered either way.
---
Roy---
On Nov 19, 2012, at 2:54 PM, Roy Stogner wrote:
>
> On Mon, 19 Nov 2012, Kirk, Benjamin (JSC-EG311) wrote:
>
>> Paul and I have been back and forth on installing the example
>> binaries - if you think it is important I could do it…
>
> I'd vote "no" but wouldn't be bothered either way.
My fe
On Nov 19, 2012, at 11:19 AM, Roy Stogner wrote:
>
> On Mon, 19 Nov 2012, Kirk, Benjamin (JSC-EG311) wrote:
>
>> Yup, working on it now. for obvious reasons I don't want to add
>> them to the repository, so I'm looking for a source forge/github
>> file upload space we can use…
>
> Why not ju
Why is the snapshot useful? Do you really want to encourage people to
use it? People will modify their snapshot and have no real way to
keep up to date... leading to all sorts of problems down the road...
Derek
Sent from my iPhone
On Nov 19, 2012, at 2:42 PM, "Kirk, Benjamin (JSC-EG311)"
wrot
On Nov 19, 2012, at 3:54 PM, Derek Gaston wrote:
> Why is the snapshot useful? Do you really want to encourage people to
> use it? People will modify their snapshot and have no real way to
> keep up to date... leading to all sorts of problems down the road…
Among other things, it is a fallback
On Mon, 19 Nov 2012, Kirk, Benjamin (JSC-EG311) wrote:
> I would say we create a
>
> /home/pfs/project/libmesh/libmesh/libmesh-daily
>
> on frs.sourceforge.net
>
> and upload the tarballs created by 'make distcheck' iff distcheck
> successfully completes.
Sounds good.
> Problem is I can only c
On Nov 19, 2012, at 4:12 PM, Roy Stogner wrote:
> On a barely related topic:
>
> What's with the need for specific LIBMESH_ENABLE_FPARSER testing in
> example Makefiles? Shouldn't that be part of the general
> LIBMESH_INCLUDE construction?
Before doing make install, fparser's header files are
On Nov 19, 2012, at 4:22 PM, "Kirk, Benjamin (JSC-EG311)"
wrote:
> On Nov 19, 2012, at 4:12 PM, Roy Stogner wrote:
>
>> On a barely related topic:
>>
>> What's with the need for specific LIBMESH_ENABLE_FPARSER testing in
>> example Makefiles? Shouldn't that be part of the general
>> LIBMESH
27 matches
Mail list logo
