1 / 5

Generalization and externalization of the Trilinos package-based system

Generalization and externalization of the Trilinos package-based system. Roscoe A. Bartlett Trilinos Software Engineering Technologies and Integration Lead Computer Science and Mathematics Div Trilinos User Group Meeting, November 3, 2011. Motivations.

cian
Télécharger la présentation

Generalization and externalization of the Trilinos package-based system

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Generalization and externalization of the Trilinos package-based system Roscoe A. Bartlett Trilinos Software Engineering Technologies and Integration Lead Computer Science and Mathematics Div Trilinos User Group Meeting, November 3, 2011

  2. Motivations • Provide a powerful, ready-made build/test/development environment for projects • All the bells and whistles of Trilinos but change the name from “Trilinos” to “MyProject” and define your own list of packages and TPLs. • Have other projects with native build systems that are automatically compatible with the Trilinos build system • Example: CASL-related software like Denovo, SCALE, Hydra, etc. • Define a meta-build system compatible with Trilinos but not rooted with Trilinos • Example: “VERA” CASL project with Trilinos as one set of packages • Solve the TPL problem by having TPLs build as compatible up-stream packages • Example: Have a “TrilinosTPLs” project that can be configured to build and install Trilinos necessary TPLs

  3. Proposal Google Docs Document

  4. Open Questions • What do we call it? • CMakePackageArch? TrilinosCMakePackageArch? TrilinosSESystem? … ??? • How much do we put in it? Segment it? • Parts? A) Minimal CMake-only macros for building and local testing, B) Extra automated CMake/CTest/Python testing scripts for CI and Nightly testing, C) Extra Trilinos tools (e.g., commonTools), D) ??? • How to we set up the development and integration model? • Option A: Make CMakePackageArchProject the primary Git repo • Host CMakePackageArchProject on trilinos.org (with controls) • Snapshot changes from external repo into Trilinos/cmake/CMakePackageArch directory (manual and CI cron jobs) • Option B: Make Trilinos the primary Git repo • Source under Trilinos/cmake/CMakePackageArch in main Trilinos git repo • Changes snapshotted into CMakePackageArchProject/cmake/CMakePackageArch(manual and CI Cron jobs) • Who will be involved in the refactoring and joint ownership?

  5. Next Steps and Other Considerations • Timing is Now! • This work will be started on Monday Nov. 7, 2011 • Some version of this must be completed by Nov. 30, 2011 (to satisfy a CASL L3 milestone) • Risk mitigation: • Changes will be controlled like any Trilinos software (others given access to push changes as needed) • We need to make these important decisions right away • What do we call it? • What initial development model do we set up for? • Who will be involved in this refactoring effort and help take joint ownership? • But relax, we can change our minds later if needed

More Related