Re: Build Warnings: spotting them, and cleaning them up

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 16/11/2016, Gregory Farnum wrote:
> It turns out, Jenkins assumes the build is good if the build script
> returns 0 — it doesn't know anything about the actual text output and
> doesn't scan for warnings.
> I'm not sure how hard it would be to change things from that end. From
> the *compilation* end, Casey suggests the "nicest" thing would be to
> set the -Werr flag, which turns all warnings into errors. Since we
> like warning-free code, that's definitely appealing to me.
> Unfortunately, we've got a problem: boost is notorious for build
> warnings. At the moment, I'm only seeing one (repeated many times
> over) resulting from use of the "remove_whitespace" iterator
> functionality in RGW. Does anybody know a good way to handle that?

I have a fix for this in my Clangtastic branch, it turns off warnings
in the building of boost and makes inluded boost a system include.

> We also have another (seemingly real) warning: the BlueStore
> BitAllocator says there are missing return statements in
> BmapEntry::operator new [](size_t). I didn't look at the code; maybe
> it's failing to detect return statements in an if-else block. But that
> should be fixed up as well.

I have a fix for that I'm about to push, I just have it return nullptr
and mark it noexcept.

(We could also make it throw something and remove the assert entirely,
but this is more in tune with the current pattern.)

> 1) The Ceph source should build warning-free. If we have warnings
> from external code we still trust, we need a way to suppress *only*
> those warnings so that issues we introduce can easily be detected.

This is in principle fairly easily done with cmake hackery. Either
marking something as a system include path or fiddling the build flags
per-target.

> 2) Patches that generate new warnings should not be merged.

I agree while-heartedly!

-- 
Senior Software Engineer           Red Hat Storage, Ann Arbor, MI, US
IRC: Aemerson@{RedHat, OFTC, Freenode}
0x80F7544B90EDBFB9 E707 86BA 0C1B 62CC 152C  7C12 80F7 544B 90ED BFB9
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [CEPH Users]     [Ceph Large]     [Information on CEPH]     [Linux BTRFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux