Firstly... let me say that you guys can do what you like.... but I'm going
to hardcode whatever paths are necessary into our Makefiles to maintain the
status quo. I don't have any problem with the way it is now... and I
really don't want to have to remember what (sometimes arbitrary) directory
a header file is in. I also don't care to have "libmesh/" all over the
danged place... nor do I want my users to have to remember to do that.
On Thu, Sep 13, 2012 at 10:34 AM, Kirk, Benjamin (JSC-EG311) <
benjamin.kir...@nasa.gov> wrote:
> include/base/* -> include/base/libmesh/*
> include/enums/* -> include/enums/libmesh/*
>
Wait - are you saying you're literally going to add a libmesh directory
under base and enums and put all the source there? That sounds _awful_ and
annoying anytime you're working in the libmesh source tree.
If you _really_ want that behavior you could just use symlinks (so you
would have a symlink in /include/base named "libmesh" that pointed to
/include/base). But that is still odd.
As for Paul's newest email.... I will reiterate (from the whole Automake
discussion) that we don't want to work against an "installed" libMesh...
that creates extra hassle for our users.
Honestly... just like with Automake... I just don't see the point in
changing something that is working fine. Has anyone ever complained about
this? What is the use case that is driving this change?
Derek
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
