Hi Paul
Generally agree on the approach while I have some questions:
1. Do we need to add branch handling? For example, I am a developer
of gp-xerces,
I need to test my branch code.
2. Let me double confirm about the build process. Below is gp-xerces repo
and now HAWQ will be commit a. So I will set commit file gp-xerces.commit
in HAWQ repo which indicate we will use commit a. And then sometime later,
we want to use b, then we commit gp-xerces.commit to b right? And we
will have multiple .commit file for each submodule now. right?
gp-xerces:
commit c
....
commit b
....
commit a
Thanks
Jiali
On Thu, Jun 30, 2016 at 11:03 AM, Radar Da lei <[email protected]> wrote:
> +1
> Since 'git clone' is called automatically in Makefile, I feel this is much
> better than use submodule.
>
> Regards,
> Radar
>
> On Thu, Jun 30, 2016 at 10:07 AM, Lili Ma <[email protected]> wrote:
>
> > Hi Paul,
> >
> > I have one question, you mentioned "if I update gp-xerces commit number
> in
> > the commit file gp-xerces.commit make will trigger an auto-build". Could
> > we set the $(gp_xerces_commit) to any commit number? What I mean is,
> could
> > we set it to a commit number already existing in my local code, or from
> > remote code which I have not fetched?
> >
> > If the answer is yes, I totally agree this suggestion.
> >
> > Thanks
> > Lili
> >
> > On Wed, Jun 29, 2016 at 11:52 PM, Kavinder Dhaliwal <
> [email protected]>
> > wrote:
> >
> > > +1. I am in favor of this approach, especially if the submodules make
> the
> > > source tarball difficult to build. I also agree it will make a
> developers
> > > life much easier.
> > >
> > > On Wed, Jun 29, 2016 at 3:18 AM, Guo Gang <[email protected]> wrote:
> > >
> > > > I'm proposing this change because:
> > > >
> > > > 1) We are ready to release the first apache release with "source
> > > tarball",
> > > > but
> > > > submodule is not friendly to source tarball since git submodule
> > > > require a git parent.
> > > >
> > > > 2) With more and more development, I found that submodule mechanism
> > > > is not that friendly for development, e.g.
> > > >
> > > > If the commit number of one submodule is modified, it is hard to
> > > detect
> > > > this for Makefile. We need to manually update it in an old repo.
> If
> > > > using "git clone", we could easily detect update by set a commit
> > > number
> > > > file
> > > > as dependency and thus easily update the code.
> > > >
> > > > Some developers have complained the annoying output in "git
> status"
> > > > after building submodules. With "git clone" we can easily mask
> those
> > > > directories via .gitignore.
> > > >
> > > > It is hard for developers who is not familiar with submodule
> > (Frankly
> > > > speaking
> > > > I really do not think submodule is friendly) to manipulate related
> > > > directories
> > > > when necessary.
> > > >
> > > > While with the "git clone" solution, we save the commit of previous
> > > > submodule in a file,
> > > > and the related Makefile code change is rather simple, e.g. for
> > > gp-xerces.
> > > >
> > > > $(ORCA_BLD_PATH)/gp-xerces_prepare_timestamp:
> > > > $(ORCA_SRC_PATH)/gp-xerces.commit
> > > > rm -f $(ORCA_BLD_PATH)/gp-xerces_prepare_timestamp
> > > >
> > > > gp-xerces_prepare: $(ORCA_BLD_PATH)/gp-xerces_prepare_timestamp
> > > > if [ ! -f $(ORCA_BLD_PATH)/gp-xerces_prepare_timestamp ]; then \
> > > > [ "x$(gp_xerces_commit)" != "x" ] || exit 1; \
> > > > cd $(abs_top_srcdir)/$(subdir); mkdir -p gp-xerces; cd
> > > gp-xerces; \
> > > > [ ! -d .git ] && git clone
> > > > https://github.com/greenplum-db/gp-xerces.git .; \
> > > > git reset --hard $(gp_xerces_commit) || exit 2; \
> > > > touch $(ORCA_BLD_PATH)/gp_xerces_prepare_timestamp; \
> > > > fi
> > > >
> > > > With above code change, if I update gp-xerces commit number in the
> > commit
> > > > file
> > > > gp-xerces.commit make will trigger an auto-build, If I messed up the
> > > > gp-xerces directory
> > > > I can easily remove the whole gp-xerces, or just remove the timestamp
> > > file
> > > > gp-xerces_prepare_timestamp to trigger an auto build.
> > > >
> > > > Any suggestion? Thanks.
> > > >
> > >
> >
>
