From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-09-13 15:07:17
|
OK, there might be some resistance to this, but... I've been thinking about putting a little include file header safety into libMesh. Basically, right now all our header files have to have unique names because their directories get added to the include path. Further, none of these can have the same names as any header files in user code. This could easily be fixed by not specifying the the include/... subdirectories to the compiler, so #include "dof_map.h" becomes #include "base/dof_map.h" or maybe even better #include "libmesh/base/dof_map.h" We could even keep the old functionality through a configure option, which we set to suppress adding the extra paths. On trunk we set this option to suppress the extra paths but could turn it on for a release or two... -Ben |
From: Roy S. <roy...@ic...> - 2012-09-13 15:23:58
|
On Thu, 13 Sep 2012, Kirk, Benjamin (JSC-EG311) wrote: > OK, there might be some resistance to this, but... >From a software reusability standpoint, it was a lousy mistake not to put our headers into the closest thing C/C++ has to a "namespace", and we should have fixed it around the same time we were wrapping all our global names into a real namespace. We definitely want either #include "libmesh/dof_map.h" or #include "libmesh/base/dof_map.h" in the long run. But from a backwards compatibility standpoint, I always thought it would be too tricky to juggle this around without immediately horribly breaking everyone's code. However, if you can work out a configure option such that old-style and new-style include statements both work for a release or two (the same way we're in the middle of doing things with the namespace libMesh) then I'd love to see this change. --- Roy |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-09-13 15:36:34
|
> #include "libmesh/base/dof_map.h" > in the long run. That's easy enough. the plan would be to make $LIBMESH_ROOT/include/libmesh and move our current $LIBMESH_ROOT/include/* there. > But from a backwards compatibility standpoint, I always thought it > would be too tricky to juggle this around without immediately horribly > breaking everyone's code. However, if you can work out a configure > option such that old-style and new-style include statements both work > for a release or two (the same way we're in the middle of doing things > with the namespace libMesh) then I'd love to see this change. Should be really easy to do. By default I'll have -I$LIBMESH_ROOT/include only, which will require full path specification in include statements. But configure can add -I$LIBMESH_ROOT/include/libmesh/base ... for backwards compatibility as needed. Obviously this won't allow us to have foo.h in multiple directories until we totally eliminate the backwards compatibility, but that's OK... -Ben |
From: Paul T. B. <ptb...@gm...> - 2012-09-13 15:53:35
|
On Thu, Sep 13, 2012 at 10:36 AM, Kirk, Benjamin (JSC-EG311) < ben...@na...> wrote: > > > #include "libmesh/base/dof_map.h" > > in the long run. > > That's easy enough. > > the plan would be to make > > $LIBMESH_ROOT/include/libmesh > > and move our current > > $LIBMESH_ROOT/include/* there. > +1 from me on this. Happy to help out. Best, Paul |
From: Roy S. <roy...@ic...> - 2012-09-13 16:50:46
|
On Thu, 13 Sep 2012, Kirk, Benjamin (JSC-EG311) wrote: > Obviously this won't allow us to have foo.h in multiple directories > until we totally eliminate the backwards compatibility, but that's > OK... Well personally I don't *want* us to ever have foo.h in multiple directories, I just want users to be able to include us alongside *other* libraries that define foo.h without their code breaking. --- Roy |
From: John P. <pet...@cf...> - 2012-09-13 16:20:09
|
On Thu, Sep 13, 2012 at 9:06 AM, Kirk, Benjamin (JSC-EG311) <ben...@na...> wrote: > OK, there might be some resistance to this, but... > > I've been thinking about putting a little include file header safety into > libMesh. Basically, right now all our header files have to have unique > names because their directories get added to the include path. Further, none > of these can have the same names as any header files in user code. > > This could easily be fixed by not specifying the the include/... > subdirectories to the compiler, so > > #include "dof_map.h" > > becomes > > #include "base/dof_map.h" > > or maybe even better > > #include "libmesh/base/dof_map.h" Better because more unique? Feels a little "boost"y to me, but I guess I could get used to it. > We could even keep the old functionality through a configure option, which > we set to suppress adding the extra paths. On trunk we set this option to > suppress the extra paths but could turn it on for a release or two... Hmm... I wouldn't mind just going cold turkey on switching this over. I don't think people will start switching over their apps in the meantime, as long as the default configure option maintains the status-quo. -- John |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-09-13 16:34:25
|
On 9/13/12 11:19 AM, "John Peterson" <pet...@cf...> wrote: >> #include "libmesh/base/dof_map.h" > > Better because more unique? Feels a little "boost"y to me, but I > guess I could get used to it. better because I still want sudirectories to organize the header files. #include "libmesh/dof_map.h" would be fine but would require we create a libmesh directory inside each of our current subdirectories, and it is the only thing in there. So we'd have include/base/* -> include/base/libmesh/* include/enums/* -> include/enums/libmesh/* ... which seems a little strange at first thought but then again may be better - after all if we want to move a header between subdirectories why should a user care or have to update code? Hmm... I'm kinda reversing myself on that one... Thoughts?? >> We could even keep the old functionality through a configure option, which >> we set to suppress adding the extra paths. On trunk we set this option to >> suppress the extra paths but could turn it on for a release or two... > > Hmm... I wouldn't mind just going cold turkey on switching this over. Yeah, I meant cold turkey on trunk but when we package up a distribution temporarily re-enabling the extra search paths. I'll get started on this. hardest part for me will be the script to fix all our existing stuff... regex'ing was never a strength! -Ben |
From: Paul T. B. <ptb...@gm...> - 2012-09-13 16:39:31
|
On Thu, Sep 13, 2012 at 11:34 AM, Kirk, Benjamin (JSC-EG311) < ben...@na...> wrote: > On 9/13/12 11:19 AM, "John Peterson" <pet...@cf...> > wrote: > > >> #include "libmesh/base/dof_map.h" > > > > Better because more unique? Feels a little "boost"y to me, but I > > guess I could get used to it. > > better because I still want sudirectories to organize the header files. > > #include "libmesh/dof_map.h" > > would be fine but would require we create a libmesh directory inside each > of > our current subdirectories, and it is the only thing in there. So we'd > have > > include/base/* -> include/base/libmesh/* > include/enums/* -> include/enums/libmesh/* > ... > You shouldn't need to do this in the source. We could retain the current directory infrastructure in the source and use the build system to install everything in $LIBMESH_INSTALL/include/libmesh/ I like this because you can still have uniqueness wrt to libmesh headers but without creating a large directory hierarchy. Of course, this is predicated that one will be buidling apps against the install and not the source. |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-09-13 16:45:49
|
On 9/13/12 11:39 AM, "Paul T. Bauman" <ptb...@gm...> wrote: > would be fine but would require we create a libmesh directory inside each of > our current subdirectories, and it is the only thing in there. So we'd have > > include/base/* -> include/base/libmesh/* > include/enums/* -> include/enums/libmesh/* > ... > > You shouldn't need to do this in the source. We could retain the current > directory infrastructure in the source and use the build system to install > everything in $LIBMESH_INSTALL/include/libmesh/ Well, that assumes we have a 'make install' - which only exists in automake now... But even then when we are building the library internally to the build system and the header files have not been redistributed by an install rule we'd need to be able to find them, which I think would require a move as described, right? Enough of us develop libMesh and apps I'd hate to have to mentally say #include "dof_map.h" when editing libmesh source files but have to switch to #include "libmesh/dof_map.h" when using the external API... -Ben |
From: Paul T. B. <ptb...@gm...> - 2012-09-13 16:50:38
|
On Thu, Sep 13, 2012 at 11:45 AM, Kirk, Benjamin (JSC-EG311) < ben...@na...> wrote: > > > But even then when we are building the library internally to the build > system and the header files have not been redistributed by an install rule > we'd need to be able to find them, which I think would require a move as > described, right? This is true, if you're wanting to make the changes internally to libMesh. I was misunderstanding and thought you were only thinking of apps not the library itself. |
From: Derek G. <fri...@gm...> - 2012-09-13 16:45:31
|
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) < ben...@na...> 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 |
From: Paul T. B. <ptb...@gm...> - 2012-09-13 16:48:31
|
On Thu, Sep 13, 2012 at 11:45 AM, Derek Gaston <fri...@gm...> wrote: > Has anyone ever complained about this? What is the use case that is > driving this change? > I haven't complained, but I've already hit several cases where I had to rename my own header file because it collided with a libMesh header name. This would fix any further possibilities of this happening. |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-09-13 16:58:47
|
On 9/13/12 11:48 AM, "Paul T. Bauman" <ptb...@gm...> wrote: >> Has anyone ever complained about this? What is the use case that is driving >> this change? > I haven't complained, but I've already hit several cases where I had to rename > my own header file because it collided with a libMesh header name. This would > fix any further possibilities of this happening. Likewise. For example, we have 'utility.h' just hanging out there, thereby precluding users from having the same. Really? So it's more than the classes, which was your reply... and it's not just for the users, but when some poorly constructed project we decide to interface with also has a utility.h - what then? -Ben |
From: John P. <pet...@cf...> - 2012-09-13 17:04:08
|
On Thu, Sep 13, 2012 at 10:58 AM, Kirk, Benjamin (JSC-EG311) <ben...@na...> wrote: > On 9/13/12 11:48 AM, "Paul T. Bauman" <ptb...@gm...> wrote: > >>> Has anyone ever complained about this? What is the use case that is driving >>> this change? > >> I haven't complained, but I've already hit several cases where I had to rename >> my own header file because it collided with a libMesh header name. This would >> fix any further possibilities of this happening. > > Likewise. For example, we have 'utility.h' just hanging out there, thereby > precluding users from having the same. Really? > > So it's more than the classes, which was your reply... > > and it's not just for the users, but when some poorly constructed project we > decide to interface with also has a utility.h - what then? How 'bout we rename all our headers from foo.h to libmesh_foo.h? Hmm... originally I was going to post this as a joke, but maybe it's simpler than messing with configure/make stuff? -- John |
From: Roy S. <roy...@ic...> - 2012-09-13 17:09:05
|
On Thu, 13 Sep 2012, John Peterson wrote: > How 'bout we rename all our headers from foo.h to libmesh_foo.h? > > Hmm... originally I was going to post this as a joke, but maybe it's > simpler than messing with configure/make stuff? I'd expect it to be much more complex, especially for maintaining backwards compatibility. Adding an include path and an option to remove a dozen others has got to be simpler than renaming hundreds of files and an option to add hundreds of symlinks. --- Roy |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-09-13 17:11:35
|
>>> I haven't complained, but I've already hit several cases where I had to >>> rename >>> my own header file because it collided with a libMesh header name. This >>> would >>> fix any further possibilities of this happening. >> >> Likewise. For example, we have 'utility.h' just hanging out there, thereby >> precluding users from having the same. Really? >> >> So it's more than the classes, which was your reply... >> >> and it's not just for the users, but when some poorly constructed project we >> decide to interface with also has a utility.h - what then? > > How 'bout we rename all our headers from foo.h to libmesh_foo.h? > > Hmm... originally I was going to post this as a joke, but maybe it's > simpler than messing with configure/make stuff? Well, if you guys have such a vested interest in insulating Moose users from our churn, why make them responsible for knowing our header names at all? You could create your own libmesh.h which includes all our headers - hell, and then even create a precompiled header out of it! -Ben |
From: Derek G. <fri...@gm...> - 2012-09-13 17:18:18
|
On Thu, Sep 13, 2012 at 11:11 AM, Kirk, Benjamin (JSC-EG311) < ben...@na...> wrote: > Well, if you guys have such a vested interest in insulating Moose users > from > our churn, why make them responsible for knowing our header names at all? > > You could create your own libmesh.h which includes all our headers - hell, > and then even create a precompiled header out of it! > Heh - we are actually heading in this direction. Unfortunately not all compilers handle precompiled headers similarly... so we've hit some snags there. And if you create a precompiled header... and you _don't_ precompile it (because a particular compiler doesn't work with PCH) then your compile time will be ridiculous for that platform. Even now our users don't typically have to #include libmesh headers... but it does happen in certain advanced circumstances... but you are right that we can work to mitigate that. At any rate... we've been talking this over here and I have an addendum to my previous suggestion of using symlinks. How about we leave our include / src tree exactly the way that it is... but off to the side we grow an "include tree" that is as ridiculously complicated as we want... and just symlinks in the header file directories at the point we want. Then you have the -I include lines use this "include tree". So basically you have one structure that is good for development (which is the current structure) and then we have another structure that is good for includes that symlinks into the first structure... Derek |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-09-13 17:38:37
|
> So basically you have one structure that is good for development (which is the > current structure) and then we have another structure that is good for > includes that symlinks into the first structure... I like this idea and am working towards something like that... -Ben |
From: Roy S. <roy...@ic...> - 2012-09-13 18:07:23
|
On Thu, 13 Sep 2012, Kirk, Benjamin (JSC-EG311) wrote: >> So basically you have one structure that is good for development (which is the >> current structure) and then we have another structure that is good for >> includes that symlinks into the first structure... > > I like this idea and am working towards something like that... How do we need symlinks, again? Move e.g. include/base/ to include/libmesh/base/ Change the current include path options to match. Add another include path of "-I$LIBMESH_DIR/include". And add a configure option to remove the current-style paths. Done. --- Roy |
From: Derek G. <fri...@gm...> - 2012-09-13 18:17:43
|
On Thu, Sep 13, 2012 at 12:07 PM, Roy Stogner <roy...@ic...>wrote: > Move e.g. include/base/ to include/libmesh/base/ > Change the current include path options to match. > Add another include path of "-I$LIBMESH_DIR/include". > And add a configure option to remove the current-style paths. > Done. > This seems fine to me. Another option is to put a "libmesh" symlink underneath include that points to include... so #include "libmesh/base" will work fine... then no source files need to be moved... and you don't have to traverse the extra directory when you're working in libMesh... Derek |
From: Roy S. <roy...@ic...> - 2012-09-13 18:23:10
|
On Thu, 13 Sep 2012, Derek Gaston wrote: > Another option is to put a "libmesh" symlink underneath include that > points to include... so #include "libmesh/base" will work fine... > then no source files need to be moved... and you don't have to > traverse the extra directory when you're working in libMesh... Hmm... that's a pretty slick way to handle in-place builds. But with a "make install" target I think we'd want to clean up our current "dozen subdirectories under $prefix/include" with a single $prefix/include/libmesh top level include directory anyway. --- Roy |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-09-13 18:59:26
|
>> Another option is to put a "libmesh" symlink underneath include that >> points to include... so #include "libmesh/base" will work fine... >> then no source files need to be moved... and you don't have to >> traverse the extra directory when you're working in libMesh... Also, WRT: > How do we need symlinks, again? > > Move e.g. include/base/ to include/libmesh/base/ > Change the current include path options to match. > Add another include path of "-I$LIBMESH_DIR/include". > And add a configure option to remove the current-style paths. > Done. Both these options work fine, and are an equivalent way to go. The only downside is that the user needs to know the subdirectory the header lives in, and change the path if we move it. On the other hand, an alternative option is to create include/libmesh and then link all the headers in there. So, any preferences? #include "libmesh/dof_map.h" or #include "libmesh/base/dof_map.h" -Ben |
From: Derek G. <fri...@gm...> - 2012-09-13 19:01:54
|
On Thu, Sep 13, 2012 at 12:59 PM, Kirk, Benjamin (JSC-EG311) < ben...@na...> wrote: > So, any preferences? > > #include "libmesh/dof_map.h" > > or > > #include "libmesh/base/dof_map.h" > #include "dof_map.h" ;-) But seriously... I do like "libmesh/dof_map.h" more than the other as long as it doesn't screw up the directories inside include / src too much... Derek |
From: Paul T. B. <ptb...@gm...> - 2012-09-13 19:06:21
|
On Thu, Sep 13, 2012 at 1:59 PM, Kirk, Benjamin (JSC-EG311) < ben...@na...> wrote: > > So, any preferences? > > #include "libmesh/dof_map.h" > This one is mine. |
From: Roy S. <roy...@ic...> - 2012-09-13 20:21:45
|
I think I'd prefer "libmesh/base/dof_map.h", but given time to reflect I might change my mind, and it looks like I'm outvoted regardless. --- Roy |