From: Benjamin K. <ben...@na...> - 2008-09-17 07:07:03
|
I am about to check in a substantial change set that prefixes every variable in include/base/libmesh_config.h with LIBMESH_ to avoid conflicts with external packages. I found an autoconf macro designed to do just that. The process is a little convoluted and deserves some explanation. Because of all the builtin variables (SIZEOF_INT, etc...) it is not as simple as changing all out AC_DEFINES(HAVE_ to AC_DEFINE(LIBMESH_HAVE_ What happens is the last step of ./configure goes through libmesh_config.h and prefixes everything with LIBMESH_ So, the aclocal.m4 code will say AC_DEFINE(HAVE_MPI), but the actual symbol will be LIBMESH_HAVE_MPI. That is a little confusing, I know, but it was the most straightforward implementation. -Ben PS: in doing this, I came across the following, which replaces strings in a list of files in place usage: ./greplace STRING1 STRING2 ./src/*/*.C ./include/*/*.h #!/bin/sh # # greplace # # Globally replace one string with another in a set of files # src=$1 shift dest=$1 shift /usr/bin/perl -p -i -e "s/$src/$dest/g" $@ |
From: Derek G. <fri...@gm...> - 2008-09-17 07:12:38
|
This sounds good Ben... thanks for looking into it. How hard was it to go through the code and change all of the #ifdefs and such? Derek On Sep 17, 2008, at 8:06 AM, Benjamin Kirk wrote: > I am about to check in a substantial change set that prefixes every > variable > in include/base/libmesh_config.h with LIBMESH_ to avoid conflicts with > external packages. > > I found an autoconf macro designed to do just that. The process is > a little > convoluted and deserves some explanation. > > Because of all the builtin variables (SIZEOF_INT, etc...) it is not as > simple as changing all out AC_DEFINES(HAVE_ to AC_DEFINE(LIBMESH_HAVE_ > What happens is the last step of ./configure goes through > libmesh_config.h > and prefixes everything with LIBMESH_ > > So, the aclocal.m4 code will say AC_DEFINE(HAVE_MPI), but the actual > symbol > will be LIBMESH_HAVE_MPI. That is a little confusing, I know, but > it was > the most straightforward implementation. > > -Ben > > PS: in doing this, I came across the following, which replaces > strings in a > list of files in place > > usage: > ./greplace STRING1 STRING2 ./src/*/*.C ./include/*/*.h > > #!/bin/sh > > # > # greplace > # > # Globally replace one string with another in a set of files > # > > src=$1 > shift > dest=$1 > shift > > /usr/bin/perl -p -i -e "s/$src/$dest/g" $@ > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win > great prizes > Grand prize is a trip for two to an Open Source event anywhere in > the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Libmesh-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-devel |
From: Benjamin K. <ben...@na...> - 2008-09-17 08:33:30
|
> How hard was it to go through the code and change all of the #ifdefs > and such? Not too bad with that perl one-liner. It took me longer to find the proper autoconf-way to get LIBMESH_ in front of everything... -Ben |
From: John P. <jwp...@gm...> - 2008-09-17 07:13:04
|
On Wed, Sep 17, 2008 at 9:06 AM, Benjamin Kirk <ben...@na...> wrote: > I am about to check in a substantial change set that prefixes every variable > in include/base/libmesh_config.h with LIBMESH_ to avoid conflicts with > external packages. > > I found an autoconf macro designed to do just that. The process is a little > convoluted and deserves some explanation. > > Because of all the builtin variables (SIZEOF_INT, etc...) it is not as > simple as changing all out AC_DEFINES(HAVE_ to AC_DEFINE(LIBMESH_HAVE_ > What happens is the last step of ./configure goes through libmesh_config.h > and prefixes everything with LIBMESH_ Awesome! I added a #define recently with a LIBMESH_ prefix for PETSc. Feel free to change that so it's not LIBMESH_LIBMESH_BLAH :-) Also... are you doing this all from your blackberry or is your internet already back? -- John |
From: Derek G. <fri...@gm...> - 2008-09-17 07:14:18
|
On Sep 17, 2008, at 8:12 AM, John Peterson wrote: > Also... are you doing this all from your blackberry or is your > internet already back? LOL - if he is doing this all from his Blackberry then I'm going to buy one tonight! Derek |
From: Roy S. <roy...@ic...> - 2008-09-18 13:25:33
|
On Wed, 17 Sep 2008, Benjamin Kirk wrote: > I am about to check in a substantial change set that prefixes every variable > in include/base/libmesh_config.h with LIBMESH_ to avoid conflicts with > external packages. I'm copying this to libmesh-users to make sure everyone sees it. As I just discovered when getting back to some of my old code, this macro change can be more sneaky than an API renaming at the symbol level: at least when a symbol name changes, you notice when it doesn't compile, and you fix it. With these macro name changes, the effect to some of my code was to silently disable features when the application didn't think "HAVE_*" was defined. Also, and this is a completely irrelevant remark that may lower the IQ of anyone who reads it: Doesn't the singular noun with misconjugated verb, "LIBMESH_HAVE_", make our config code now sound just a little like it was written by cavemen? --- Roy |
From: John P. <jwp...@gm...> - 2008-09-18 13:36:29
|
On Thu, Sep 18, 2008 at 3:25 PM, Roy Stogner <roy...@ic...> wrote: > Also, and this is a completely irrelevant remark that may lower the IQ > of anyone who reads it: Doesn't the singular noun with misconjugated > verb, "LIBMESH_HAVE_", make our config code now sound just a little > like it was written by cavemen? LIBMESH_MAKE_FIRE -- John |