On Jan 23, 2013, at 10:16 PM, Derek Gaston <fried...@gmail.com> wrote:
> A couple of more things about the new build system when trying to make a new > example with in-tree builds: > > 1. Compiling using "make check" is not a good solution: > a. It means my Emacs hooks for compiling in Emacs don't work (small > thing... but hacking lisp to make Emacs realize that you're in an example > directory and to run "make check" is actually harder than you might think!) > b. It compiles both the opt and dbg versions of the example (I can't seem > to make it stop doing that... I tried setting METHOD and METHODS... but no > matter what it goes with how I configured the code). I could reconfigure to > only do one or the other, but I really need to do both on and off while > developing. This is true. The make rules and build targets are set at compile time. Vikram has requested we build the strictest target first, so that errors appear as soon as possible, and I think that is a good idea. > c. The fact that it runs run.sh every time (in both opt and debug no less) > is annoying. Sometimes that is hanging in opt or debug mode and I have to > stop it so I can run the debugger instead (more on this later) run.sh will respect runtime changes to METHODS. So $ make check # will run all METHODS set at configure time $ make check METHODS="dbg" # will run only the dbg method > > 2. Having to update Makefile.am and rebootstrap and reconfigure (even with > the config.status trick) to add (or remove) any new files is cumbersome: > a. If you accidentally delete the Makefile for your example you have to > actually rerun "make" at the root level to get it recreated. This was > definitely not clear to me (I spent a while running bootstrap, configure and > autoconf before I figured it out) The interesting thing about configure is that all it creates is config.status, and config.status then generates all the Makefiles for you. This was the case with the old system too, we just used it to create far fewer Makefiles. So if you want to rerun configure with your last options you can do $./config.status --recheck but if you accidentally (or intentionally) deleted a file that configure creates you can get it back just by doing $ ./config.status For example: $ rm Makefile $ ./config.status # (voila!) > Guys... I'm still not buying this new build system. Developing in libMesh > has definitely become much more cumbersome. It is tedious to even mess with > libMesh now. It doesn't have any sort of "flow" during development. No > matter what you are doing you end up "dealing with" the new system. Jumping > in and out of thinking about the problem you are trying to solve and the > manipulations you need to do to the build system at the moment. FWIW, I was not a fan at all when my application code was ported to autotools a few years back, but after a painful startup process I became such a believer I obviously decided to inflict the joy on others. Like any new technology, the annoyances become obvious much sooner than the benefits. -Ben ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
