For gporca it is ok to pre-build them and pass orca installation path to hawq, but for pgcrypto and plr, having a script to run before building hawq seems to not be a good idea, technically speaking.
plr/pgcrypto depends on the configure options and configure checking. (e.g. with and without openssl option in configure, pgcrypto build results will be different). That means building of these features are not 100% independent on building of hawq. 2016-07-07 0:03 GMT+08:00 Roman Shaposhnik <[email protected]>: > On Wed, Jul 6, 2016 at 4:35 AM, Gmail <[email protected]> wrote: > > I think the method using git clone is fine. > > > > But I suggest we'd better keep the makefile readable. I mean we should > not add too trivial shell logic inside makefile itself. > > For example, write a shell or Python script for users. Users should run > the script before building HAWQ if they need to install this libraries. > > Huge +1 to the above. That's what I was suggesting in my previous > emails saying that > you should allow users to make dependencies available and then just > point at them. > > > I also wonder what's the typical solution for similar problems of other > Apache projects. > > Typically solution is to make sure that your build logic is capable of > picking up > binary dependencies. > > > Do they use git sub module? > > Not really. Most ASF projects have a single repo for the project (docs > and site source > code being an exception) and their dependency management is done through > binary > dependencies. > > > How do they solve this in their release? > > When you say 'release' this gets me slightly worried in the context of > Git submodules. > See, releases of ASF projects must be self-contained to a degree. If > you require source > in the Git submodule for the release to be functional it should give > you a pretty strong > indication that the source probably belongs to your project. If what > submodules does > is more of a plugin -- just declare a binary dependency. > > Thanks, > Roman. >
