(crap, thought I sent this!!)
> Ben, Paul, would you mind if I changed the macros like
> CONFIGURE_EXODUS to take "if-true" and "if-false" arguments (like e.g.
> $2 and $3 in AX_BOOST_BASE), then move anything libmesh.automake
> specific (e.g. AC_CONFIG_FILES calls) into their caller macro
> (pro
On Thu, 19 Apr 2012, Kirk, Benjamin (JSC-EG311) wrote:
> And this is trunk?
>
> My guess is that $(top_srcdir) is not getting set without automake?
That's it. I'll fix it.
---
Roy
--
For Developers, A Lot Can Happen In
On 4/19/12 6:37 PM, "John Peterson" wrote:
> After updating to 5570 on the automake branch, I now get errors about
> missing sfcurves.h header...
>
>
> I am building in a subdirectory of the SVN checkout. The steps I followed
> were:
>
>
> ./bootstrap
> mkdir opt_build
> cd opt_build
> ../co
On 4/19/12 6:44 PM, "John Peterson" wrote:
> And here's some wrong looking include paths printed from 'make echo'.
>
> They all point to /contrib, which is just wrong...
>
> -I/contrib/gzstream
> -I/contrib/gmv
> -I/contrib/tetgen
> -I/contrib/triangle
> -I/contrib/exodusii/Lib/include
>
On Thu, Apr 19, 2012 at 5:42 PM, John Peterson wrote:
> On Thu, Apr 19, 2012 at 5:03 PM, Roy Stogner wrote:
>>
>> I'm merging a bunch of Ben's m4 file changes (after modifying them to
>> be compatible with trunk and adding one bug fix) in from branch. All
>> looks correct on first examination, b
On Thu, Apr 19, 2012 at 5:03 PM, Roy Stogner wrote:
>
> I'm merging a bunch of Ben's m4 file changes (after modifying them to
> be compatible with trunk and adding one bug fix) in from branch. All
> looks correct on first examination, but anyone doing an svn up in the
> next 24 hours or so might
After updating to 5570 on the automake branch, I now get errors about
missing sfcurves.h header...
I am building in a subdirectory of the SVN checkout. The steps I followed were:
./bootstrap
mkdir opt_build
cd opt_build
../configure --with-method=opt --prefix=/path/to/libmesh/opt_install
make
I'm merging a bunch of Ben's m4 file changes (after modifying them to
be compatible with trunk and adding one bug fix) in from branch. All
looks correct on first examination, but anyone doing an svn up in the
next 24 hours or so might want to double-check the results of
rerunning configure.
---
R
On 4/19/12 3:26 PM, "Roy Stogner" wrote:
> It's almost certainly a bug in Ubuntu autotools. But if it's an
> Ubuntu issue that has persisted through two freaking years then it'd
> be nice of us to have a workaround. There's got to be some workaround
> - we build lots of automake-based apps here
Ben, Paul, would you mind if I changed the macros like
CONFIGURE_EXODUS to take "if-true" and "if-false" arguments (like e.g.
$2 and $3 in AX_BOOST_BASE), then move anything libmesh.automake
specific (e.g. AC_CONFIG_FILES calls) into their caller macro
(probably libmesh_optional_packages.m4)? We
On Thu, 19 Apr 2012, Kirk, Benjamin (JSC-EG311) wrote:
> (1) The Make.common. I just fixed in r5565 and am testing it.
Thanks!
> (2) The bash/dash nonsese I have working at home on ubuntu 11.10 by setting
> the CONFIG_SHELL environment variable to /bin/bash, forcing it to use the
> right shell.
>>> I can't seem to figure a workaround; one major drawback of automake is
>>> how damn opaque it is.
>>
>> Thanks - actually I just hit this a minute ago on cygwin 1.7. I'll work up
>> a fix...
>
> Thanks! Turns out this hits me on Ubuntu 11.10 too. I should have
> tried out the branch on mor
On Thu, 19 Apr 2012, Kirk, Benjamin (JSC-EG311) wrote:
>> I can't seem to figure a workaround; one major drawback of automake is
>> how damn opaque it is.
>
> Thanks - actually I just hit this a minute ago on cygwin 1.7. I'll work up
> a fix...
Thanks! Turns out this hits me on Ubuntu 11.10 to
> I can't seem to figure a workaround; one major drawback of automake is
> how damn opaque it is.
Thanks - actually I just hit this a minute ago on cygwin 1.7. I'll work up
a fix...
--
For Developers, A Lot Can Happen I
If we configure with no METHOD defined, instead of defaulting to opt
we just get a "Make.common." with no suffix. If we then build with no
METHOD defined, it dies complaining that it can't find
Make.common.opt.
We seem to be getting hit by this bug:
https://bugs.launchpad.net/ubuntu/+source/libt
On Thu, 19 Apr 2012, Kirk, Benjamin (JSC-EG311) wrote:
1812 roystgnr * This function is now deprecated - write the
1812 roystgnr * libmesh-devel mailing list if you need it reimplemented.
598 benkirk */
598 benkirk void delete_system (const std::string& name);
So
Just happened across an application where EquationSystems::delete_system()
might be quite useful, so I went to check the docs...
598benkirk /**
598benkirk* Remove the system named \p name from the systems array.
1812 roystgnr* This function is now deprecated - write th
17 matches
Mail list logo
