On Wed, Nov 21, 2012 at 8:08 PM, Paul T. Bauman <ptbau...@gmail.com> wrote:
> On Wed, Nov 21, 2012 at 5:43 PM, Roy Stogner <royst...@ices.utexas.edu>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.
>
No - it was not a surprise. However, I've been holding out hope that
somehow we would avoid merging that branch. I voiced my opinion on the
matter several times back when it was proposed. I lost that debate, so the
merge went forward.
> There's been lots of time to test these things. There've been multiple
> offers from Ben and myself to help facilitate this. Ben has been
> extraordinarily responsive in helping people with the transition (which
> will have inevitable hiccups) and trying to accommodate requests for the
> behavior of the build system. And instead of trying to provide examples
> that are breaking that could be added into a regression suite, the
> responses that come back are "I am straight up frustrated with the state
> of the repo at the moment" which is not helpful for anyone.
>
There is no regression test that will tell you that it's frustrating to
work with the new build system when compared to the old. Getting user
feedback is an important process for any software... and "I'm frustrated
with your recent changes" is valid and important feedback. I didn't say
that "everything is broken, fix it!" without giving an example. I simply
stated that the new system, for me, is frustrating.
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 -j24
Then, I would make a change in some file in libMesh and rebuild using:
make && METHOD=dbg make
Nothing is simpler than that.
Now let's examine the new system:
svn up
./bootstrap # if even possible
mkdir build_opt
cd build_opt
../configure --prefix=~/libmesh_install
make -j24
make install
cd ..
mkdir build_dbg
cd build_dbg
export METHOD=dbg
../configure --prefix=~/libmesh_install
make -j24
make install
Then I go make a change to libMesh and need to do:
cd build_opt
make
make install
cd ..
cd build_dbg
export METHOD=dbg
make
make install
Every single change I must now go into two different directories to build
AND I must run "make install" for each one. "make install" BTW is a
non-trivial operation. On slow network filesystems it can take a
significant amount of time. We were trying to debug the PETSc issue we're
having with the new build system yesterday... and holy smokes it is
frustrating to make a tiny change then have to wait around while cd'ing to
different directories and building and make installing. It is FRUSTRATING.
Is the new system "unusable"? Absolutely not? Is it worse (in my opinion)
than the old system for a normal development cycle for libMesh? Yes. When
you are going through that cycle MANY times per day, it is tiresome. Yes,
I can write a script (and I already did)... but why should I have to? The
old system worked perfectly fine without it.
Derek
------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
