hawq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Zhanwei Wang <wan...@apache.org>
Subject Re: enforce -Werror (if gcc) in hawq?
Date Tue, 06 Sep 2016 01:52:22 GMT
Hi Hong

I removed -Werror flag when we push HAWQ to open source. In Pivotal we build HAWQ on specific
OS with specific GCC and dependent libraries. -Werror flag worked fine since we fix all warnings.
But for a open source project. It is impossible to make users and contributors to build HAWQ
on specific OS and compiler just like what we did before. We cannot say we just support HAWQ
on Centos 6 with GCC 4.4.2.

So if we enforce -Werror flag, I guess the build will fail on many environments.

I propose three solutions and let’s discuss which is better.

1) Do not enforce -Werror flag but add it to our test (concourse and Travis) like this.
./configure —prefix=/path/to/install CFLAGS=“-Werror”

By this way we can enforce -Werror flag on our tested environment.


2) Only enforce -Werror flag on development build, remove it on release build.


3) Enforce -Werror flag and we setup more test environments(different versions of CentOS Ubuntu
SUSE with default compiler and latest GCC and MacOS with default compiler and latest clang)


Any comments?


Best Regards

Zhanwei Wang
wangzw@apache.org



> 在 2016年9月6日,上午9:22,Ed Espino <espino@apache.org> 写道:
> 
> +1
> 
> Have we considered setting up separate public Concourse pipelines to try
> the various build scenarios.
> 
> -=e
> 
> On Tue, Sep 6, 2016 at 12:58 AM, Hong Wu <xunzhangthu@gmail.com> wrote:
> 
>> Ming's comment makes sense, but I think it is another thread. I have
>> already tried those[1] but there are some further works need to do[2].
>> 
>> [1]
>> - clang analysis scan report: I uploaded the result of not that fresh HAWQ
>> in my personal link, please check the report out here
>> <http://xunzhangthu.org/tmp/hawq_check> if you are interested.
>> - coverity scan: the latest reported is here
>> <https://scan.coverity.com/projects/apache-incubator-hawq>. If you want to
>> see the defects in detail, you need to submit a permission request.
>> 
>> [2]
>> - Make clang analysis scan reported generating periodically and publishing
>> to the public automatically. I suggest we donate a domain such as hawq.io
>> and
>> a host for it, also for automatically publishing the report, we need to
>> write a web service to reply the requests and transmitting html data.
>> 
>> - Travis CI script have already integrated the coverity scan service using
>> github webhook. we need to create a coverity_scan branch for hawq and then
>> modify the .travis.yml file. I have done that under Redhat environment.
>> While the only environment Travis server supports for Linux is
>> Ubuntu/Debian. Although hawq could be built under Ubuntu, it needs extra
>> effort to extend the .travis.yml script to support that. For osx
>> environment, I am not sure what the problem is, the issue is that the
>> report could not be sent to the coverity scan server automatically.
>> 
>> ps: I think Chunlin <https://github.com/wcl14> is starting working on the
>> defects generated by coverity.
>> 
>> 
>> Back to main thread mentioned by Paul, I think we should just try to open
>> the flag and discuss errors after opening -Werror.
>> 
>> Best
>> Hong
>> 
>> 
>> 2016-09-05 21:51 GMT+08:00 Ming Li <mli@pivotal.io>:
>> 
>>> Good suggestion.
>>> 
>>> However, IMHO, we may need to firstly enable coverity scan check or clang
>>> analysis scan. Also we should make the output of these check on a public
>>> server so that all contributor can access them.
>>> 
>>> On Mon, Sep 5, 2016 at 6:05 PM, Paul Guo <paulguo@gmail.com> wrote:
>>> 
>>>> -Werror
>>>> Make all warnings into errors.
>>>> I've seen many cases (not just hawq) before that ignoring gcc warning
>>> leads
>>>> to bugs. I'm wondering we should add the option for the gcc case. Given
>>>> there may be a lot of warnings when building the common postgres code
>> in
>>>> hawq, we could at least enforce it in our own code at first
>>>> (src/backend/cdb, src/backend/resourcemanager, src/test/feature, other
>>>> directories?)? Any suggestion?
>>>> 
>>> 
>> 
> 
> 
> 
> -- 
> *Ed Espino*


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message