On Nov 21, 2012, at 7:26 PM, "Roy Stogner"
mailto:royst...@ices.utexas.edu>> wrote:
On Wed, 21 Nov 2012, Paul T. Bauman wrote:
Should we just select some subset of existing examples and add the
build system
My initial thought would be to create a new examples/builds/
directory; in each subdi
On Wed, Nov 21, 2012 at 9:53 PM, Kirk, Benjamin (JSC-EG311) <
benjamin.kir...@nasa.gov> wrote:
> On Nov 21, 2012, at 7:21 PM, Derek Gaston wrote:
> Thanks for the vote of confidence, and I apologize for getting short with
> you over this…
>
No problem at all. God knows I've gotten short with en
On Nov 21, 2012, at 7:21 PM, Derek Gaston wrote:
> Let me explain a little more: I love libMesh. I think it's an awesome
> triumph of scientific framework software. I am constantly in awe at all the
> thought put into the way the system works. All of that thought went into
> creating a lib
On Wed, Nov 21, 2012 at 7:15 PM, Derek Gaston wrote:
>
> No distcc! I have a dual hexa-core hyperthreaded (12 "real" cores, 24
> "logical") workstation with three solid state drives in RAID0. make -j24
> is optimal (I've done the studies!). On my workstation, make install does
> not take that
On Wed, Nov 21, 2012 at 9:07 PM, Paul T. Bauman wrote:
> The only difference between this and the former build system is the extra
> cd's (minor annoyance) and make install (nice new feature, IMHO, that was
> not present in the previous build system).
>
Gotcha.
> Again, I don't see that much o
On Wed, Nov 21, 2012 at 6:44 PM, Derek Gaston wrote:
> I simply stated that the new system, for me, is frustrating.
>
Fair enough.
> Since you are asking, let me give you an example:
>
> In the old system, this was my libMesh workflow.
>
> svn up
> ./configure && make -j24 && METHOD=dbg make -
On Wed, Nov 21, 2012 at 8:08 PM, Paul T. Bauman wrote:
> On Wed, Nov 21, 2012 at 5:43 PM, Roy Stogner wrote:
>
>>
>> > quit bitching
>>
>> This wasn't called for.
>
>
> I'll support Ben here. This branch has been around for months. There's
> been lots of discussion of "hey, we're going to merge t
On Wed, Nov 21, 2012 at 6:21 PM, Derek Gaston wrote:
> Let me just say: Happy Thanksgiving Everyone! I really appreciate and am
> thankful for the opportunity to work (and debate!) with all of you! ;-)
>
Couldn't have put it better myself. +1. Happy turkey day all.
Best,
Paul
---
On Wed, 21 Nov 2012, Paul T. Bauman wrote:
> Should we just select some subset of existing examples and add the
> build system
My initial thought would be to create a new examples/builds/
directory; in each subdirectory use the same plain, dumb code (maybe
my heatsystem.C code with an even-more-
On Wed, Nov 21, 2012 at 7:25 PM, Kirk, Benjamin (JSC-EG311) <
benjamin.kir...@nasa.gov> wrote:
> Understood, but CI only works when everyone can see results of tests.
> Libmesh.automake has been passing its tests for months, and Paul and I use
> it in production.
>
You and Paul are not average us
On Wed, Nov 21, 2012 at 4:16 PM, Roy Stogner wrote:
>
> Certainly. If we're brainstorming wishlist-y, I'd actually like to
> provide multiple examples of *build systems* too - one a two-part
> Makefile with a stripped down "Make.common" that does a better job of
> separating PETSc/SLEPc/libMesh/e
On Wed, Nov 21, 2012 at 5:43 PM, Roy Stogner wrote:
>
> > quit bitching
>
> This wasn't called for.
I'll support Ben here. This branch has been around for months. There's been
lots of discussion of "hey, we're going to merge this into trunk soon".
There's absolutely no way this was a surprise. T
On Wed, 21 Nov 2012, Kirk, Benjamin (JSC-EG311) wrote:
> If you want to point users to our trunk we need to see your test
> results. Period.
This is a good point. I'd feel much much happier about my
"libmesh/testing gets synched to trunk when it passes tests" plan if
those tests included all th
On Wed, 21 Nov 2012, Derek Gaston wrote:
> Stating that "they can download nightlies" or "we have time until
> 0.9.0" doesn't do justice to the reality that many people are using
> the library right out of the repo.
"They can download nightlies" isn't an attempt to make things harder
for users,
On Nov 21, 2012, at 5:39 PM, "Derek Gaston" wrote:
> I am straight up frustrated with the state of the repo at the moment.
>
> Derek
Understood, but CI only works when everyone can see results of tests.
Libmesh.automake has been passing its tests for months, and Paul and I use it
in product
> We have time to iterate this though, not like I want to ship 0.9.0
> tomorrow!
>
Maybe we should do a poll to see how many of our users are using released
versions of libMesh. I would say it is nearly zero. I know of over a
hundred who are exclusively using the SVN version of libMesh: our user
On Wed, 21 Nov 2012, Kirk, Benjamin (JSC-EG311) wrote:
Mostly because 'include our makefile' is frowned upon…
Right - but it wouldn't be "our makefile", with a billion
internally-used identifiers and things that might break other build
systems; it would be "our provided make rules", specifica
On Nov 21, 2012, at 4:58 PM, Roy Stogner wrote:
>>
>> I'd also like to get some feedback on this approach since these
>> self-contained examples should be the way people get introduced to
>> the library, and I want to set good 'best practices' with the
>> Makefile!
>
> Best practices are that y
On Wed, 21 Nov 2012, Kirk, Benjamin (JSC-EG311) wrote:
> I'd like to rework the makefile not to include Make.common, and that
> means moving the compile rules into it directly.
Why? In my experience, when you hand users ten copies of the
same original Makefile (or when you so much as make it ea
19 matches
Mail list logo
