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.
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)
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)
3. The "executables" created... aren't really executables. Jed mentioned
this but it didn't sink in. I was just trying to debug my example and for
the life of me I couldn't figure out why this wasn't working:
gdb ./example-dbg
GNU gdb (GDB) 7.5
...
"/Users/gastdr/projects/libmesh/examples/mesh_transfer/ex1_simple_dtk/example-dbg":
not in executable format: File format not recognized
I was so confused that (because I just installed new compilers and thought
that maybe there was an incompatibility between the executables created by
it and the GDB that comes with OSX) I went and downloaded the newest GDB
source release and compiled and installed it... only to find that it didn't
fix the problem.
It wasn't until I remembered what Jed said that I actually checked the
"executables" with the file command:
> file example-dbg
example-dbg: POSIX shell script text executable
Ah! So I just need to go into the .libs directory to run the executable
right?
> cd .libs
> ./example-dbg
dyld: Library not loaded: /usr/local/lib/libmesh_dbg.0.dylib
Referenced from:
/Users/gastdr/projects/libmesh/examples/mesh_transfer/ex1_simple_dtk/.libs/./example-dbg
Reason: image not found
Trace/BPT trap: 5
Nope. Apparently those scripts modify the environment to get all the right
library paths into your environment (why don't the executables get linked
with proper -r flags so that's unnecessary?).
So how do I even run an example in a debugger? Well, I'm leaning towards
modifying the automatically generated script to run "gdb ./example-dbg"...
or writing my own little script instead.
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.
I know I'm stepping into "whining" territory again... but I still believe
we took a step backward here.
Derek
On Mon, Jan 21, 2013 at 2:29 PM, John Peterson <jwpeter...@gmail.com> wrote:
> On Sat, Jan 19, 2013 at 7:06 PM, John Peterson <jwpeter...@gmail.com>
> wrote:
> >
> > On Jan 19, 2013, at 5:08 PM, Derek Gaston <fried...@gmail.com> wrote:
> >
> > On Sat, Jan 19, 2013 at 4:57 PM, Derek Gaston <fried...@gmail.com>
> wrote:
> >>
> >> Hmmm.... we did some testing with this this week and there are a couple
> of
> >> issues:
> >>
> >> 1. If you don't "make install" then Make.common does not get created
> >> (obviously not necessary for an example... but that is problematic for
> some
> >> users).
> >>
> >> 2. If you don't "make install" then bin/libmesh_config doesn't output
> the
> >> proper include directories (or are we doing something wrong?). Coupled
> with
> >> #1 this means that not make installing doesn't seem to be an option for
> >> actual application development... but are we missing something?
> >
> >
> > BTW - We didn't report these issues because when we noticed this we all
> > agreed that we must have been remembering wrong... and that in-tree
> builds
> > really weren't supported. Otherwise I would have pinged you guys about
> it.
> >
> > Now that I know that in-tree builds should work, I'll help work out the
> > kinks...
> >
> >
> > The "uninstalled" libmesh-config script did not print the right paths for
> > the --include switch. We immediately got build errors about not finding
> > libmesh header files. May have something to do with the fact that we are
> > still use legacy include paths?
>
> So I fixed the issue I mentioned previously. Basically, with an
> in-tree (uninstalled) build, if you still specify
>
> --prefix=$LIBMESH_DIR
>
> to configure even though you don't plan to 'make install' the library
> there, you will get $LIBMESH_DIR/include/libmesh in your compiler
> search paths.
>
>
> This gets us a bit further, but our build next dies when it tries to
> find the "exodusII.h" header file -- the problem is, for an installed
> libmesh exodusII.h (and other contrib headers) get installed into
>
> $LIBMESH_DIR/include/libmesh
>
> but this doesn't happen for an uninstalled libmesh. That header is
> still hidden away in contrib/exodusii/Lib/include where it lives in
> the distribution.
>
> --
> John
>
------------------------------------------------------------------------------
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
