> On Mar 6, 2017, at 10:29 AM, Jacob Barrett <jbarr...@pivotal.io> wrote: > > On Mon, Mar 6, 2017 at 9:56 AM Anthony Baker <aba...@pivotal.io> wrote: > > - The distributions don’t include the version in the top-level directory. > We should include that. > > I believe you are looking for `make package_source`. No care has been taken > yet for a src target. Some CMakeList.txt work needs to be tackled. The > first thing is that the root CMakeLists.txt needs to be moved to the root > of the repo. In fact the whole src directory is probably ready to be moved > to the root. It was under a sub directory for migration purposes only. > >
I’d prefer the top-level directory in the archives to be named something like 'apache-geode-native-1.2.0-Linux-x64bit' instead of ‘apache-geode-native’. Is that hard in cmake? > - It looks like src/cppcache/src/version.cmake.in relies on the presence of > a git repo. That will not be present for a source release, see [1]. > > > This should be easy to change to fallback to something if .git is not > found. It currently pulls the revisions SHA out of the repo. Personally I > think that is silly and we should just remove it altogether. The other > option is that a src distribution would just ship version.h and not cmake > bits to determine it. > Is version.h dumped to the log anywhere? That info can be really useful. > > We also need to generate signatures and hashes for each of the distribution > artifacts. How hard is that to do in cmake? Should we just create a > simple gradle wrapper script to do this so we have a common release toolset > across geode, geode-examples, and geode-native? > > > I really dislike having yet another build tool. CMake 3.7.2 and newer > supports hashing directly in CPack. Older versions of CMake support hashing > directly in the FILE command. > Signatures are easy enough to achieve with a custom target call to openssl > or pgp. Ok, sounds good. Anthony
