I might have missed this - what's the rationale behind changing binary dependency to git submodule (or git clone in this proposal) (e.g. gporca) in the first place?
On Wed, Jul 6, 2016 at 9:03 AM Roman Shaposhnik <[email protected]> wrote: > 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. >
