Re: [petsc-users] PETSc testing recipes
Thank you all for the info! > On Apr 14, 2023, at 3:48 PM, Jacob Faibussowitsch wrote: > > More specifically for configure handling of C++ dialect. It has 3 modes: > > 1. You don’t specify any C++ dialect (i.e. configure without passing > `--with-cxx-dialect`): > > Configure will determine the dialect range for your given setup. It takes > into account all of the compilers (including “extra” ones like nvcc) it > finds, as well as all of your requested packages. It will also enable GNU > extensions if they are available, i.e. passing `-std=gnu++17` over > `-std=c++17`. From this range, it will select the highest possible dialect > and apply it to all builds. > > 2. You specify `--with-cxx-dialect=14`: > > Configure will do the above but will impose an arbitrary cap of C++14. If > something in your environment conflicts with this (i.e. maybe your compiler > doesn’t support it, or maybe a package requires C++17) it will produce a hard > error telling you why this won’t work. It still attempts to enable GNU > extensions as above. > > 3. You specify `--with-cxx-dialect=c++14` OR you have `-std=c++14` in > `[--]CXXFLAGS` and/or `[--]CXXOPTFLAGS`: > > configure assumes you know something it doesn’t. It will blindly apply > exactly `-std=c++14` everywhere. This includes building PETSc itself and all > packages that PETSc builds. It will still check your compiler supports > `-std=c++14` though (and error if it does not). > > So if your goal is to have the highest available dialect chosen for you, do > nothing. Do not pass any dialect flags, and do not set them in your > `CXXFLAGS` or `CXXOPTFLAGS`. Configure will do The Right Thing. > > If your goal is to explicitly set the dialect, we recommend using option 2 > since that might still allow you to enable GNU extensions. > > If something is just not working then 1. send us your configure.log — maybe > we have a bug — and 2. use option #3, it will do exactly as you ask. > > Best regards, > > Jacob Faibussowitsch > (Jacob Fai - booss - oh - vitch) > >> On Apr 14, 2023, at 18:18, Satish Balay via petsc-users >> wrote: >> >> Hm depending on what you are seeking - you'll have to look at multiple >> places [and co-related the info from them] >> >> - you can check one of the pipelines to see exactly what jobs are run (and >> the logs of the jobs for details). for ex: >> https://gitlab.com/petsc/petsc/-/pipelines/836609909 >> >> - most of the build scripts are at config/examples/arch-ci-*.py - so thats >> one way to get a view of what pkgs are tested by what jobs.. >> >> balay@p1 /home/balay/petsc (main =) >> $ ls config/examples/arch-ci-*.py |wc -l >> 56 >> >> - And wrt specific examples corresponding to external pkg - say - >> superlu_dist - you can do something like: >> >> balay@p1 /home/balay/petsc (main =) >> $ git grep 'requires:' src |grep superlu_dist |head -5 >> src/ksp/ksp/tests/ex17.c: requires: superlu_dist complex >> src/ksp/ksp/tests/ex17.c: requires: superlu_dist complex >> src/ksp/ksp/tests/ex33.c: requires: superlu_dist !complex >> src/ksp/ksp/tests/ex33.c: requires: superlu_dist !complex >> src/ksp/ksp/tests/ex49.c: requires: superlu_dist >> >> etc. >> >> - Wrt C++ dialect: >> >> balay@p1 /home/balay/petsc (main =) >> $ git grep self.minCxxVersion config/BuildSystem/config/packages >> config/BuildSystem/config/packages/AMReX.py:self.minCxxVersion = >> 'c++14' >> config/BuildSystem/config/packages/h2opus.py:self.minCxxVersion >> = 'c++14' >> config/BuildSystem/config/packages/kokkos.py:self.minCxxVersion= >> 'c++17' >> config/BuildSystem/config/packages/raja.py:self.minCxxVersion = >> 'c++14' >> config/BuildSystem/config/packages/sycl.py:self.minCxxVersion= >> 'c++17' >> balay@p1 /home/balay/petsc (main =) >> $ git grep self.maxCxxVersion config/BuildSystem/config/packages >> config/BuildSystem/config/packages/MOAB.py:self.maxCxxVersion = >> 'c++14' >> config/BuildSystem/config/packages/amgx.py:self.maxCxxVersion= >> 'c++17' # https://github.com/NVIDIA/AMGX/issues/231 >> config/BuildSystem/config/packages/elemental.py:self.maxCxxVersion= >> 'c++14' >> config/BuildSystem/config/packages/grid.py:self.maxCxxVersion = 'c++17' >> config/BuildSystem/config/packages/kokkos.py:self.maxCxxVersion= >> 'c++17' >> >> However configure determines the max that the compiler supports and >> attempts to use that [when only min is set]. And this info is usually >> in configure.log [or make.log] for the corresponding build. >> >> Satish >> >> >>> On Fri, 14 Apr 2023, Alexander Lindsay wrote: >>> >>> Hi, is there a place I can look to understand the testing recipes used in >>> PETSc CI, e.g. what external packages are included (if any), what C++ >>> dialect is used for any external packages built with C++, etc.? >>> >>> Alex >>> >> >
Re: [petsc-users] PETSc testing recipes
More specifically for configure handling of C++ dialect. It has 3 modes: 1. You don’t specify any C++ dialect (i.e. configure without passing `--with-cxx-dialect`): Configure will determine the dialect range for your given setup. It takes into account all of the compilers (including “extra” ones like nvcc) it finds, as well as all of your requested packages. It will also enable GNU extensions if they are available, i.e. passing `-std=gnu++17` over `-std=c++17`. From this range, it will select the highest possible dialect and apply it to all builds. 2. You specify `--with-cxx-dialect=14`: Configure will do the above but will impose an arbitrary cap of C++14. If something in your environment conflicts with this (i.e. maybe your compiler doesn’t support it, or maybe a package requires C++17) it will produce a hard error telling you why this won’t work. It still attempts to enable GNU extensions as above. 3. You specify `--with-cxx-dialect=c++14` OR you have `-std=c++14` in `[--]CXXFLAGS` and/or `[--]CXXOPTFLAGS`: configure assumes you know something it doesn’t. It will blindly apply exactly `-std=c++14` everywhere. This includes building PETSc itself and all packages that PETSc builds. It will still check your compiler supports `-std=c++14` though (and error if it does not). So if your goal is to have the highest available dialect chosen for you, do nothing. Do not pass any dialect flags, and do not set them in your `CXXFLAGS` or `CXXOPTFLAGS`. Configure will do The Right Thing. If your goal is to explicitly set the dialect, we recommend using option 2 since that might still allow you to enable GNU extensions. If something is just not working then 1. send us your configure.log — maybe we have a bug — and 2. use option #3, it will do exactly as you ask. Best regards, Jacob Faibussowitsch (Jacob Fai - booss - oh - vitch) > On Apr 14, 2023, at 18:18, Satish Balay via petsc-users > wrote: > > Hm depending on what you are seeking - you'll have to look at multiple places > [and co-related the info from them] > > - you can check one of the pipelines to see exactly what jobs are run (and > the logs of the jobs for details). for ex: > https://gitlab.com/petsc/petsc/-/pipelines/836609909 > > - most of the build scripts are at config/examples/arch-ci-*.py - so thats > one way to get a view of what pkgs are tested by what jobs.. > > balay@p1 /home/balay/petsc (main =) > $ ls config/examples/arch-ci-*.py |wc -l > 56 > > - And wrt specific examples corresponding to external pkg - say - > superlu_dist - you can do something like: > > balay@p1 /home/balay/petsc (main =) > $ git grep 'requires:' src |grep superlu_dist |head -5 > src/ksp/ksp/tests/ex17.c: requires: superlu_dist complex > src/ksp/ksp/tests/ex17.c: requires: superlu_dist complex > src/ksp/ksp/tests/ex33.c: requires: superlu_dist !complex > src/ksp/ksp/tests/ex33.c: requires: superlu_dist !complex > src/ksp/ksp/tests/ex49.c: requires: superlu_dist > > etc. > > - Wrt C++ dialect: > > balay@p1 /home/balay/petsc (main =) > $ git grep self.minCxxVersion config/BuildSystem/config/packages > config/BuildSystem/config/packages/AMReX.py:self.minCxxVersion = > 'c++14' > config/BuildSystem/config/packages/h2opus.py:self.minCxxVersion > = 'c++14' > config/BuildSystem/config/packages/kokkos.py:self.minCxxVersion= > 'c++17' > config/BuildSystem/config/packages/raja.py:self.minCxxVersion = > 'c++14' > config/BuildSystem/config/packages/sycl.py:self.minCxxVersion= 'c++17' > balay@p1 /home/balay/petsc (main =) > $ git grep self.maxCxxVersion config/BuildSystem/config/packages > config/BuildSystem/config/packages/MOAB.py:self.maxCxxVersion = > 'c++14' > config/BuildSystem/config/packages/amgx.py:self.maxCxxVersion= > 'c++17' # https://github.com/NVIDIA/AMGX/issues/231 > config/BuildSystem/config/packages/elemental.py:self.maxCxxVersion= > 'c++14' > config/BuildSystem/config/packages/grid.py:self.maxCxxVersion = 'c++17' > config/BuildSystem/config/packages/kokkos.py:self.maxCxxVersion= > 'c++17' > > However configure determines the max that the compiler supports and > attempts to use that [when only min is set]. And this info is usually > in configure.log [or make.log] for the corresponding build. > > Satish > > > On Fri, 14 Apr 2023, Alexander Lindsay wrote: > >> Hi, is there a place I can look to understand the testing recipes used in >> PETSc CI, e.g. what external packages are included (if any), what C++ >> dialect is used for any external packages built with C++, etc.? >> >> Alex >> >
Re: [petsc-users] PETSc testing recipes
Hm depending on what you are seeking - you'll have to look at multiple places [and co-related the info from them] - you can check one of the pipelines to see exactly what jobs are run (and the logs of the jobs for details). for ex: https://gitlab.com/petsc/petsc/-/pipelines/836609909 - most of the build scripts are at config/examples/arch-ci-*.py - so thats one way to get a view of what pkgs are tested by what jobs.. balay@p1 /home/balay/petsc (main =) $ ls config/examples/arch-ci-*.py |wc -l 56 - And wrt specific examples corresponding to external pkg - say - superlu_dist - you can do something like: balay@p1 /home/balay/petsc (main =) $ git grep 'requires:' src |grep superlu_dist |head -5 src/ksp/ksp/tests/ex17.c: requires: superlu_dist complex src/ksp/ksp/tests/ex17.c: requires: superlu_dist complex src/ksp/ksp/tests/ex33.c: requires: superlu_dist !complex src/ksp/ksp/tests/ex33.c: requires: superlu_dist !complex src/ksp/ksp/tests/ex49.c: requires: superlu_dist etc. - Wrt C++ dialect: balay@p1 /home/balay/petsc (main =) $ git grep self.minCxxVersion config/BuildSystem/config/packages config/BuildSystem/config/packages/AMReX.py:self.minCxxVersion = 'c++14' config/BuildSystem/config/packages/h2opus.py:self.minCxxVersion = 'c++14' config/BuildSystem/config/packages/kokkos.py:self.minCxxVersion= 'c++17' config/BuildSystem/config/packages/raja.py:self.minCxxVersion = 'c++14' config/BuildSystem/config/packages/sycl.py:self.minCxxVersion= 'c++17' balay@p1 /home/balay/petsc (main =) $ git grep self.maxCxxVersion config/BuildSystem/config/packages config/BuildSystem/config/packages/MOAB.py:self.maxCxxVersion = 'c++14' config/BuildSystem/config/packages/amgx.py:self.maxCxxVersion= 'c++17' # https://github.com/NVIDIA/AMGX/issues/231 config/BuildSystem/config/packages/elemental.py:self.maxCxxVersion= 'c++14' config/BuildSystem/config/packages/grid.py:self.maxCxxVersion = 'c++17' config/BuildSystem/config/packages/kokkos.py:self.maxCxxVersion= 'c++17' However configure determines the max that the compiler supports and attempts to use that [when only min is set]. And this info is usually in configure.log [or make.log] for the corresponding build. Satish On Fri, 14 Apr 2023, Alexander Lindsay wrote: > Hi, is there a place I can look to understand the testing recipes used in > PETSc CI, e.g. what external packages are included (if any), what C++ > dialect is used for any external packages built with C++, etc.? > > Alex >
Re: [petsc-users] PETSc testing recipes
Look at config/examples/arch-ci-*.py for the configurations. They're driven from .gitlab-ci.yml Alexander Lindsay writes: > Hi, is there a place I can look to understand the testing recipes used in > PETSc CI, e.g. what external packages are included (if any), what C++ > dialect is used for any external packages built with C++, etc.? > > Alex
[petsc-users] PETSc testing recipes
Hi, is there a place I can look to understand the testing recipes used in PETSc CI, e.g. what external packages are included (if any), what C++ dialect is used for any external packages built with C++, etc.? Alex
