- Apr 12, 2019
-
-
Attila Krasznahorkay authored
LCG_95 Update, master branch (2019.04.12.) See merge request atlas/atlasexternals!477
-
Attila Krasznahorkay authored
That one place somehow avoided the updates in the previous round. :-(
-
Attila Krasznahorkay authored
Mainly to make it properly functional on macOS. But it should help on other non-linux platforms as well.
-
- Apr 11, 2019
-
-
Attila Krasznahorkay authored
Unfortunately the TBB makefiles are not working correctly on such a platform, they need to be patched a bit. See ROOT-9678 for more information.
-
Attila Krasznahorkay authored
-
Attila Krasznahorkay authored
-
Attila Krasznahorkay authored
-
Attila Krasznahorkay authored
Now that we can use C++17 with the new version of Eigen that we pick up from LCG as well.
-
Attila Krasznahorkay authored
-
Attila Krasznahorkay authored
-
- Apr 10, 2019
-
-
Attila Krasznahorkay authored
CMake Updates, master branch (2019.04.10.) See merge request atlas/atlasexternals!475
-
Attila Krasznahorkay authored
update Eigen version (See MR 22073 ) + update VP1LightExternals README See merge request atlas/atlasexternals!474
-
-
Attila Krasznahorkay authored
While removing the LinkDef.h file scanning was definitely a good move in that code, users should still be able to provide their headers using wildcards to the function.
-
Attila Krasznahorkay authored
It turns out that in most cases the Fortran compiler is not set up yet when AtlasCompilerSettings.cmake is executed. So instead of depending on what Fortran compiler is found by CMake, the code needs to depend on what C++ compiler it found instead. And just hope that we use the same type of C++ and Fortran compiler in the job...
-
- Apr 09, 2019
-
-
Attila Krasznahorkay authored
This was yet another thing that my cleanup managed to mess up. :-(
-
Attila Krasznahorkay authored
It turns out that the "simplification" that I put into the code were all wrong. :-( So now I added some extra comments there that should prevent future blunders like this.
-
- Apr 08, 2019
-
-
Attila Krasznahorkay authored
-
Attila Krasznahorkay authored
These are the files that will be used to produce descriptions for the packages generated by CPack.
-
Attila Krasznahorkay authored
In the previous update I managed to make some mistakes. This should fix those.
-
Attila Krasznahorkay authored
Not as extensively as all the other ones, just updating the coding style in its CMakeLists.txt file a bit...
-
Attila Krasznahorkay authored
-
Attila Krasznahorkay authored
Very similar to what I did in all the other projects as well.
-
Attila Krasznahorkay authored
Similar to what I did in all the other projects as well.
-
Attila Krasznahorkay authored
First to make sure that the build uses all available CPU cores efficiently, and then updated the build setup of resolveAtlasAddr2Line to take the recent changes in atlas_add_executable(...) into account.
-
Attila Krasznahorkay authored
-
Attila Krasznahorkay authored
Similar to what was done to the other projects as well. Hiding some of its files under a cmake/ directory, and making it take the latest changes in AtlasCMake into account.
-
Attila Krasznahorkay authored
Similar to what I did in AnalysisBaseExternals. And taking into account the changes made in AtlasCMake.
-
- Apr 05, 2019
-
-
Attila Krasznahorkay authored
Moved some of the technical files into a subdirectory inside the project, and introduced a README.txt.in file that provides a project-specific README for the RPM created from this project.
-
Attila Krasznahorkay authored
-
Attila Krasznahorkay authored
The code will now just complain if one tries to use an OBJECT library with a tool old CMake version. This is to keep the ability of using slightly older CMake version for "simple builds" alive.
-
Attila Krasznahorkay authored
-
Attila Krasznahorkay authored
-
Attila Krasznahorkay authored
I used the same text that's used in atlas/athena at the moment. Though I think we should use the proper license text instead...
-
Attila Krasznahorkay authored
Moving generated files into the CMakeFiles/ directory, removing some dead code, etc.
-
- Apr 04, 2019
-
-
Attila Krasznahorkay authored
The changes are already too numerous to list. :-( In principle I'm trying to modernise all "old parts" of AtlasCMake.
-
- Apr 03, 2019
-
-
Attila Krasznahorkay authored
-
Attila Krasznahorkay authored
At the same time took the opportunity to clean up the code a bit. Mainly to kill all the "package recompilation" code from these files as well. Plus fixed a small issue in ProjectConfig-version.cmake.in. In the previous setup when re-configuring an existing build directory, the version of the exported project became an empty string. Just because of how cache variables work. Now the file is set up using a regular variable instead.
-
Attila Krasznahorkay authored
Instead of installing the object files under lib/objects/..., with this setup they will end up simply under objects/...
-
Attila Krasznahorkay authored
It's pretty silly that list(LENGTH...) and foreach(...RANGE...) don't work with compatible values...
-