Toby, > DEAL_II_USE_PETSC_VERSION_DEV should be defined as yes/no in > common/Make.global_options. deal.II 7.1.pre r24276. Can you > update and check again please? It may be that I spoke too soon > earlier... sorry.
It still is not configuring the dev version of petsc. The relevant output from config.log is below: ...skipping... /* #undef DEAL_II_USE_PETSC_VERSION_DEV */ /* Defined if a SLEPc installation was found and is going to be used */ #define DEAL_II_USE_SLEPC 1 Also, after svn update, aclocal, autoconf, ./configure --options, the script exits with an error now. checking for MUMPS library directory... no checking whether p4est will be used... no checking -framework Accelerate... yes checking for HSL subroutines... none found ./configure: line 15530: syntax error near unexpected token `newline' ./configure: line 15530: ` yes:no:' > Don't! The reason things are as they are is outlined in the information > pages of deal.II and SLEPc. I understand but unfortunately it does depend on whether slepc configure script allows this or not. Because if someone does configure a compatible petsc/slepc combination with different revisions, should Deal not go through with the configuration ? > I think you misunderstand what the interface does. I think maybe the name for the macro is confusing (DEAL_II_PETSC_VERSION_DEV). It specifically implies checking for the dev version while I was expecting something more generic that can incorporate the version numbers. > Does that make sense? If there is an obviously "better" way of doing > this, I will be happy enough to listen to your screams. :-) You could create specific DEAL_II_PETSC_VEC_DESTROY, DEAL_II_PETSC_MAT_DESTROY macros that are defined in config.h depending on the version and the code just calls the macro with no notion of version numbers. That way, everything is localized and performed during configuration (as it should be) and you dont have to change any dependent code. My 2 cents. Vijay On Wed, Sep 7, 2011 at 3:24 AM, Toby D. Young <[email protected]> wrote: > > Vijay, > >> I checked out a new repository and tried to configure/make. I see that >> config.h has "DEAL_II_USE_PETSC_VERSION_DEV" undefined even though I >> am using the dev version of petsc/slepc. I've attached config.log. I >> haven't had time to look into this yet. Let me know if you need any >> other information. > > DEAL_II_USE_PETSC_VERSION_DEV should be defined as yes/no in > common/Make.global_options. deal.II 7.1.pre r24276. Can you > update and check again please? It may be that I spoke too soon > earlier... sorry. > >> Also, I haven't tried configure a petsc-dev version with a >> slepc-release version or vice-versa. The configure script for slepc >> may disallow this but it might be worth confirming. > > Don't! The reason things are as they are is outlined in the information > pages of deal.II and SLEPc. Mixing version numbers and/or dev/release > may work... but that is definately not supported by anyone anywhere. > VERSION_MAJOR and VERSION_MINOR are supposed to be synced between PETSc > and SLEPc (deal.II checks this); patch numbers are supposed to be > backward compatible and that is why there are no checks for patch > numbersin deal.II. > >> The check on whether it is a dev version alone might not be sufficient >> for the *Destroy(&x) family of routines. This is because in the next >> version of petsc, these changes will be part of the release and your >> code branch will have compiler errors. You probably want to check for >> DEAL_II_PETSC_VERSION_GTE(3,2,0) also. > > I think you misunderstand what the interface does. When the next > version of PETSc is released (which should be in a few days) all of the > _DEV code becomes the default and the current default code gets wrapped > into 3.1. Thus for now (petsc-3.1): > > #if DEAL_II_PETSC_VERSION_DEV() > f(&x) > #else > f(x) > #endif > > will become (petsc-3.2): > > #if DEAL_II_PETSC_VERSION_LT(3,2,0) > f(x) > #else > f(&x) > #endif > > which is awkward, mainly due to an unbelievably strange choice of > numbering dev packages by PETSc, but it works. > > Since all of the code is there (and sometimes there is more) the > transition to new PETSc releases is very quick and simple. The > transition from 3.0->3.1 took me a couple of hours using this > type of conversion. There is a transition period - that will > actually happen very soon - and you will see how this works then. > > Does that make sense? If there is an obviously "better" way of doing > this, I will be happy enough to listen to your screams. :-) > > Best, > Toby > > > > -- > Toby D. Young > > Assistant Professor Philosophy & Physics > Polish Academy of Sciences > www: http://www.ippt.gov.pl/~tyoung > skype: stenografia > > _______________________________________________ dealii mailing list http://poisson.dealii.org/mailman/listinfo/dealii
