[
https://issues.apache.org/jira/browse/BIGTOP-1469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guo Ruijing updated BIGTOP-1469:
--------------------------------
Description:
Add build option for do-component-build:
1. Add build option in bigtop.mk. Example:
BUILD_OPTION="BUILD_CLEANUP=yes, BUILD_ALL=yes, BUILD_NATIVE=yes"
In default, BUILD_CLEANUP=yes and BUILD_ALL=yes. The behavior is same with
existing build behavior.
a) if BUILD_CLEANUP=yes, "rm -rf $RPM_BUILD_ROOT" is called in the beging & end
of do-component-build
b) BUILD_ALL=yes, JAR and native are rebuild.
c) BUILD_NATIVE=yes, only native are rebuild.
2. what's motivation to add BUILD_OPTION for do-component-build?
a) cleanup inconsistent code for bigtop.
some component do build cleanup and dome component doesn't do build cleanup:
[hadoop@localhost bigtop]$ find . | grep spec$ | xargs egrep -A1 %clean
./bigtop-packages/src/rpm/hue/SPECS/hue.spec:%clean
./bigtop-packages/src/rpm/hue/SPECS/hue.spec-%__rm -rf $RPM_BUILD_ROOT
...
b) It is easy to develop/debug/verify debian/RPM without rebuild
i) BUILD_OPTION="BUILD_CLEANUP=no, BUILD_ALL=no"
ii) develop/debug/verify debian/RPM without building source code.
c) it is possible to include same JAR for debian/RPM and different native for
debian/RPM
i) BUILD_OPTION="BUILD_CLEANUP=no, BUILD_ALL=yes" for RPM
BUILD_OPTION="BUILD_CLEANUP=no, BUILD_NATIVE=yes" for debian
ii) checkout/download source from SCM/URL
iii) docker1 and docker2 share same directory in host file system
iiii) docker1(RPM) build jar and native for RPM and docker2 (debian) build
native for debian. in this case, jar can be kept same for RPM & debian.
was:
Add build option for do-component-build:
1. Add build option in bigtop.mk. Example:
BUILD_OPTION="BUILD_CLEANUP=yes, BUILD_ALL=yes, BUILD_NATIVE=yes"
In default, BUILD_CLEANUP=yes and BUILD_ALL=yes. The behavior is same with
existing build behavior.
a) if BUILD_CLEANUP=yes, "rm -rf $RPM_BUILD_ROOT" is called in the beging & end
of do-component-build
b) BUILD_ALL=yes, JAR and native are rebuild.
c) BUILD_NATIVE=yes, only native are rebuild.
2. what's motivation to add BUILD_OPTION for do-component-build
a) cleanup inconsistent code for bigtop.
some component do build cleanup and dome component doesn't do build cleanup:
[hadoop@localhost bigtop]$ find . | grep spec$ | xargs egrep -A1 %clean
./bigtop-packages/src/rpm/hue/SPECS/hue.spec:%clean
./bigtop-packages/src/rpm/hue/SPECS/hue.spec-%__rm -rf $RPM_BUILD_ROOT
...
b) It is easy to develop/debug/verify debian/RPM.
i) BUILD_OPTION="BUILD_CLEANUP=no, BUILD_ALL=no"
ii) develop/debug/verify debian/RPM without building source code.
c) it is possible to include same JAR for debian/RPM and different native for
debian/RPM
i) BUILD_OPTION="BUILD_CLEANUP=no, BUILD_ALL=yes" for RPM
BUILD_OPTION="BUILD_CLEANUP=no, BUILD_NATIVE=yes" for debian
ii) checkout/download source from SCM/URL
iii) docker1 and docker2 share same directory in host file system
iiii) docker1(RPM) build jar and native for RPM and docker2 (debian) build
native for debian. in this case, jar can be kept same for RPM & debian.
> Add build option for do-component-build
> ----------------------------------------
>
> Key: BIGTOP-1469
> URL: https://issues.apache.org/jira/browse/BIGTOP-1469
> Project: Bigtop
> Issue Type: Improvement
> Components: build
> Affects Versions: 0.9.0
> Reporter: Guo Ruijing
>
> Add build option for do-component-build:
> 1. Add build option in bigtop.mk. Example:
> BUILD_OPTION="BUILD_CLEANUP=yes, BUILD_ALL=yes, BUILD_NATIVE=yes"
> In default, BUILD_CLEANUP=yes and BUILD_ALL=yes. The behavior is same with
> existing build behavior.
> a) if BUILD_CLEANUP=yes, "rm -rf $RPM_BUILD_ROOT" is called in the beging &
> end of do-component-build
> b) BUILD_ALL=yes, JAR and native are rebuild.
> c) BUILD_NATIVE=yes, only native are rebuild.
> 2. what's motivation to add BUILD_OPTION for do-component-build?
> a) cleanup inconsistent code for bigtop.
> some component do build cleanup and dome component doesn't do build cleanup:
> [hadoop@localhost bigtop]$ find . | grep spec$ | xargs egrep -A1 %clean
> ./bigtop-packages/src/rpm/hue/SPECS/hue.spec:%clean
> ./bigtop-packages/src/rpm/hue/SPECS/hue.spec-%__rm -rf $RPM_BUILD_ROOT
> ...
> b) It is easy to develop/debug/verify debian/RPM without rebuild
> i) BUILD_OPTION="BUILD_CLEANUP=no, BUILD_ALL=no"
> ii) develop/debug/verify debian/RPM without building source code.
> c) it is possible to include same JAR for debian/RPM and different native for
> debian/RPM
> i) BUILD_OPTION="BUILD_CLEANUP=no, BUILD_ALL=yes" for RPM
> BUILD_OPTION="BUILD_CLEANUP=no, BUILD_NATIVE=yes" for debian
> ii) checkout/download source from SCM/URL
> iii) docker1 and docker2 share same directory in host file system
> iiii) docker1(RPM) build jar and native for RPM and docker2 (debian) build
> native for debian. in this case, jar can be kept same for RPM & debian.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
