libMesh: A C++ Finite Element Library

On Mon, 8 Mar 2010, Derek Gaston wrote:

> On Mar 8, 2010, at 2:41 PM, Roy Stogner wrote:
>
>> We've talked about no longer caching dependency information, and
>> getting rid of this problem for good, but:
>> 1. That can slow down make on high-latency filesystems
>> 2. We're lazy
>
> We recently switched to this for our framework and codes.... and
> have found we have far fewer problems because of it... but we're
> kind of always in development mode over here where we're adding new
> files all the time... so maybe it makes more sense for us than it
> does for libmesh (where the actual file structure and dependencies
> are more mature).

Yes... mature... I'm currently hacking up a header that, if it works
properly, will become a new dependency on most of the source files in
the library, and probably half the headers.

Your system, would you like to switch libMesh itself to use it?
Manually updating .depend files clearly is not worth it; checking just
now I find that I forgot to update it when adding tensor_value.h to
system.h, and I know I've caught others making the same sort of
mistake...
---
Roy

On Mar 8, 2010, at 3:01 PM, Roy Stogner wrote:

> Yes... mature... I'm currently hacking up a header that, if it works
> properly, will become a new dependency on most of the source files in
> the library, and probably half the headers.
> 
> Your system, would you like to switch libMesh itself to use it?
> Manually updating .depend files clearly is not worth it; checking just
> now I find that I forgot to update it when adding tensor_value.h to
> system.h, and I know I've caught others making the same sort of
> mistake...

My "system", as you put it, is just to add .depend to the PHONY line in the Makefile and take the print statement out of .depend so we don't have to see it all the time.

That's all that's necessary...

Derek

On Mon, 8 Mar 2010, Derek Gaston wrote:

> My "system", as you put it, is just to add .depend to the PHONY line
> in the Makefile and take the print statement out of .depend so we
> don't have to see it all the time.
>
> That's all that's necessary...

Yes, I think I can wrap my head around that.  ;-)

Hmm... since the .PHONY line is grammatically a dependency rather than
a variable, we ought to be able to have multiple .PHONY lines, right?
In particular, it looks like we can add:
.PHONY: .depend
to our Make.common, which then causes paranoid dependency regeneration
in all our examples as well as in any user app build systems that
mimic our example Makefiles.

I say we do it.  The biggest downside is that regenerating .depend for
the whole library takes time, but it's 1-3 seconds on the systems I
use.  Any comments/objections?
---
Roy

On Mar 8, 2010, at 3:17 PM, Roy Stogner wrote:

> Hmm... since the .PHONY line is grammatically a dependency rather than
> a variable, we ought to be able to have multiple .PHONY lines, right?
> In particular, it looks like we can add:
> .PHONY: .depend
> to our Make.common, which then causes paranoid dependency regeneration
> in all our examples as well as in any user app build systems that
> mimic our example Makefiles.

Ah good... that would actually take care of us as well... then I can remove the PHONY out of our Makefiles.

> I say we do it.  The biggest downside is that regenerating .depend for
> the whole library takes time, but it's 1-3 seconds on the systems I
> use.  Any comments/objections?

1-3 seconds is nothing compared to the actual compile time of any file in libMesh.... and it's a small price to pay for _never_ having out of date dependencies...

I say go for it!

Derek

On Mon, 8 Mar 2010, Derek Gaston wrote:

> On Mar 8, 2010, at 3:17 PM, Roy Stogner wrote:
>
>> In particular, it looks like we can add:
>> .PHONY: .depend
>> to our Make.common, which then causes paranoid dependency regeneration
>> in all our examples as well as in any user app build systems that
>> mimic our example Makefiles.
>
> Ah good... that would actually take care of us as well... then I can remove the PHONY out of our Makefiles.

I just ran into a nasty problem with this:

Since we "include .depend" in the Makefile, and .depend is considered
a phony target, it appears that make wants to regenerate it before
*every* make command.  Not just "make all", but "make echo".

contrib/bin/libmesh-config uses "make echo".

Lots of users might (in our case, do) want to use libmesh-config, even
if they don't have write access to $LIBMESH_DIR, in which case it now
breaks horribly when .depend can't be written to.

I could move targets that don't benefit from rewriting .depend to a
separate "Makefile.const" - include that in Makefile for backwards
compatibility, but use the separate file from libmesh-config.  But
that feels hackish.  Anyone have any better ideas?
---
Roy

On Fri, 19 Mar 2010, John Peterson wrote:

> Have libmesh-config process the makefile, and strip out the echo
> commands?  Looks like that's all it needs currently.

Applying regexps to our Makefile to produce another (temporary?)
Makefile?  Sounds fragile, even compared to "Makefile.const".

> Anyway, as I understand it, PHONY is really for targets such as
> "clean" which don't result in anything actually being built.  Since
> the .depend target actually builds something, what we're doing is
> already basically a hack....

True.

> Could we add .depend to the "all" target instead of making it PHONY?
> That way dependencies could be regenerated whenever you just type
> make....

This sounds pretty good.  To be as paranoid as possible we could add
.depend to the object files' dependencies, even.

But there was one thing I really liked about the PHONY .depend: it
automatically caused dependency regeneration in our example &
application builds as well.  I guess we could manually make .depend a
dependency of example/app object files, and suggest our users do the
same if they like that behavior?
---
Roy

On Fri, Mar 19, 2010 at 12:41 PM, Roy Stogner <roystgnr@...> wrote:
>
>
> On Fri, 19 Mar 2010, John Peterson wrote:
>
>> Have libmesh-config process the makefile, and strip out the echo
>> commands?  Looks like that's all it needs currently.
>
> Applying regexps to our Makefile to produce another (temporary?)
> Makefile?  Sounds fragile, even compared to "Makefile.const".
>
>> Anyway, as I understand it, PHONY is really for targets such as
>> "clean" which don't result in anything actually being built.  Since
>> the .depend target actually builds something, what we're doing is
>> already basically a hack....
>
> True.
>
>> Could we add .depend to the "all" target instead of making it PHONY?
>> That way dependencies could be regenerated whenever you just type
>> make....
>
> This sounds pretty good.  To be as paranoid as possible we could add
> .depend to the object files' dependencies, even.

Yeah, I'd add it anywhere you think it could potentially be necessary.

> But there was one thing I really liked about the PHONY .depend: it
> automatically caused dependency regeneration in our example &
> application builds as well.  I guess we could manually make .depend a
> dependency of example/app object files, and suggest our users do the
> same if they like that behavior?

That is a pretty cool feature I guess.  By the way, why not also make
.depend depend (so to say) on

.depend: $(srcfiles) $(headerfiles)

?

-- 
John

On Mar 19, 2010, at 11:48 AM, John Peterson wrote:

> That is a pretty cool feature I guess.  By the way, why not also make
> .depend depend (so to say) on
> 
> .depend: $(srcfiles) $(headerfiles)

If that's possible... it gets my vote.

Derek

Hi developers and users,

I am looking at the nonlinear system of equations and want to borrow 
some ideas from ex13, while the finite element equations in the assemble 
function make me a little confused because I am not familiar with the 
Stokes' equation, does any fluids expert might send me a image format 
PDEs of that system? or give a link which is exact same to the equations 
in ex13. I have looked at the Wikipedia but not make sure which 
equations are belong to the case of ex13. Thanks a lot!

Liang