[
https://issues.apache.org/jira/browse/MINIFICPP-947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16894006#comment-16894006
]
Mr TheSegfault commented on MINIFICPP-947:
------------------------------------------
Definitely another long lived task I think. Though this one has the potential
to have a stopping point with the arrival at warning free base – so hopeful we
can do this over time.
Extensions may need to have a pass on this since we will have many owners. We
can draw a line in the sand, but like NiFi there may be an extension that for
whatever reason abides by different principles. I don't want to preclude that
necessarily but open the discussion on that.
In my opinion we should branch out and have a discussion on what it means to
provide an extension. Without extension registry they exist in our code base.
But some extensions we don't own/know/update so they are not truly "ours" We
own libminifi and nanofi. There are some extensions that we update and support,
so perhaps we can define a way that registers extensions as apache released –
similar to maven profiles.
those extensions must be warning free to be released but won't fail compilation
otherwise.
> Fix all -Wall warnings, gradually fix or disable warnings from -Weverything
> ---------------------------------------------------------------------------
>
> Key: MINIFICPP-947
> URL: https://issues.apache.org/jira/browse/MINIFICPP-947
> Project: Apache NiFi MiNiFi C++
> Issue Type: Improvement
> Reporter: Daniel Bakai
> Priority: Major
>
> * Create macros for locally enabling and disabling warnings (pragma warning
> pop, push, etc.)
> * Compile third-parties with different warning settings than our code
> * Make serious warnings errors
> * Once we are warning-free, only merge code that does not introduce new
> warnings
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
