search

TriBITSPub / TriBITS

TriBITS: Tribal Build, Integrate, and Test System,
http://tribits.org
Other
36 stars 46 forks source link

[export files] *_PACKAGE_LIST, *_LIBRARIES too long #32

Open nschloe opened 10 years ago

nschloe commented 10 years ago

The export files are way to verbose on the *_LIBRARIES and *_PACKAGE_LIST. In Trilinos's NOX, for example we find

SET(NOX_LIBRARIES "trilinos_locathyra;trilinos_locaepetra;trilinos_localapack;trilinos_loca;trilinos_noxepetra;trilinos_noxlapack;trilinos_nox;trilinos_teko;trilinos_stratimikos;trilinos_stratimikosbelos;trilinos_stratimikosaztecoo;trilinos_stratimikosamesos;trilinos_stratimikosml;trilinos_stratimikosifpack;trilinos_ifpack2-adapters;trilinos_ifpack2;trilinos_zoltan2;trilinos_anasazitpetra;trilinos_ModeLaplace;trilinos_anasaziepetra;trilinos_anasazi;trilinos_belostpetra;trilinos_belosepetra;trilinos_belos;trilinos_ml;trilinos_ifpack;trilinos_amesos;trilinos_amesos2;trilinos_galeri-xpetra;trilinos_galeri;trilinos_aztecoo;trilinos_isorropia;trilinos_thyratpetra;trilinos_thyraepetraext;trilinos_thyraepetra;trilinos_thyracore;trilinos_xpetra-sup;trilinos_xpetra-ext;trilinos_xpetra;trilinos_epetraext;trilinos_tpetrarti;trilinos_tpetraext;trilinos_tpetrainout;trilinos_tpetra;trilinos_triutils;trilinos_zoltan;trilinos_epetra;trilinos_kokkosdisttsqr;trilinos_kokkosnodetsqr;trilinos_kokkoslinalg;trilinos_kokkosnodeapi;trilinos_kokkos;trilinos_rtop;trilinos_tpi;trilinos_teuchosremainder;trilinos_teuchosnumerics;trilinos_teuchoscomm;trilinos_teuchosparameterlist;trilinos_teuchoscore")

and

SET(NOX_PACKAGE_LIST "NOX;Teko;Stratimikos;Ifpack2;Zoltan2;Anasazi;Belos;BelosTpetra;BelosEpetra;BelosCore;ML;Ifpack;Amesos;Amesos2;Galeri;AztecOO;Isorropia;Thyra;ThyraTpetraAdapters;ThyraEpetraExtAdapters;ThyraEpetraAdapters;ThyraCore;Xpetra;EpetraExt;Tpetra;Triutils;Zoltan;Epetra;KokkosClassic;RTOp;ThreadPool;Teuchos;TeuchosRemainder;TeuchosNumerics;TeuchosComm;TeuchosParameterList;TeuchosCore")

These are literally all dependent libraries and packages, respectively.

The linking information, however, is handled much more elegantly by CMake itself, through the target export files.

We need to prune the exported libraries and packages list.

bartlettroscoe commented 10 years ago

Nico,

My worry is that this will break some client projects that use these variables. I don't so I can't say but that is my guess.

Is there a problem other than these are large set() statements? I mean, is this a performance problem?

nschloe commented 10 years ago

Whoever is using those is doing it wrong. All applications should only link against the libraries they are actually using; the rest is handled by CMake. Anyhow, at the end of the day, no application should take notice of any of these changes. My guess is that applications use, e.g.,NOX_LIBRARIES in their TARGET_LINK_LIBRARIES() calls. They should continue to do so, just that the number of libraries they explicitly link against can potentially be much, much smaller. This will certainly bring down link times for shared libraries, though I'm not sure by how much.

nschloe commented 10 years ago

As for *_PACKAGE_LIST, I have no idea of what use this list may be to any application.

bartlettroscoe commented 7 years ago

@nschloe, now that I am starting to work with these <Package>Config.cmake files as part of a little work on #63 on the branch

I definitely see what you are talking about. It looks like a <Package>Config.cmake file should only list the libraries for its direct lib dependencies. The indirect dependencies would be taken care of automatically with the import library targets, etc.

These <Package>Config.cmake files are going to be the key to allowing TriBITS to scale to a huge amount of software. Therefore, I am going to be examining these files and their dependent files in the weeks and months to come.

nschloe commented 7 years ago

Note that PR https://github.com/TriBITSPub/TriBITS/pull/60 tries to fix this. It's two and a half years old now, so it might need a little update.

bartlettroscoe commented 7 years ago

Note that PR #60 tries to fix this. It's two and a half years old now, so it might need a little update.

As part of the work I am doing right now I will need to add some stronger tests for the generated <Package>Config.cmake files. After those tests are in place, then I can take a look at PR #60 and then I can test it out to know that it will not break anything.