How to develop on a team with different compilers

[Matthew Gidden]

Hi everyone,

More than once now, our development team has had trouble when reviewing pull requests because the reviewer and reviewee compiled their source code with different compilers (gcc and clang in our case). The reviewer reported tests failing which led to a hunt down the rabbit hole. 

Does anyone have advice on how to treat this problem? In both of our cases, the problems thus far came from uninitialized POD in some classes, which is treated differently by the two compilers. I'm curious less about how to fix our code (which we are in the process of doing) and more about how the developer work flow should work when developers use different compilers. I'd really enjoy to hear any feedback.

Cheers,

blackbeard

[Katy Huff]

We should be using CDash.

--
You received this message because you are subscribed to the Google Groups "Hacker Within" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hacker-withi...@googlegroups.com.
To post to this group, send email to hacker...@googlegroups.com.
Visit this group at http://groups.google.com/group/hacker-within?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
http://katyhuff.github.com

[Matthew Gidden]

"CDash is a part of a larger software process that integrates Kitware's CMake, CTest, and CPack tools, as well as other external packages used to design, manage and maintain large-scale software systems."

Do you have to use ctest?

Matthew Gidden
Nuclear Energy University Programs Fellow
The University of Wisconsin -- Madison
Ph. 225.892.3192
Fax 608.263.7451

[Katy Huff]

I'm pretty sure you can run and report almost anything you want on CDash. (in the case of cyclus of course, we don't currently register all of our tests run as CTests, but we do register some). But yes, I think it's cleaner if all tests are CTests. It's also cleaner if you build packages with CPack (which, again, cyclus has done correctly in a small subset of cases in the past (namely, on my mac about a year ago))

[Ben Liblit]

Matthew Gidden wrote:
> how the developer work flow should work when developers
> use different compilers.

Compiler diversity can be a great benefit, because it gives you multiple
automated opinions as to whether your code is good or bad. This
especially holds true if you have any kind of automated testing suite.
Run that suite under every compiler you care about, on every platform
you care about. Do it as often as you can: ideally after each every
commit. If every platform likes your code, then your code *might* be
correct. If any platform fails tests, then apparently your code was
broken and the other systems were just letting you get lucky.

Next step up from that is to have build-and-test virtual machines, again
representing every compiler and platform you care about. At each commit
these machines pull from the repository, build, and test. Also make
these machine images available to the developers directly, so any
developer can easily test out their code in any environment you care
about. I suppose there's some clever way to manage all this using git,
but git and I are still just casual acquaintances, so I'll leave that
for others to comment on.

See also <https://nmi.cs.wisc.edu/> for a UW-Madison campus resource
that can give you access to a wide variety of different platforms,
specifically oriented toward automated building and testing. If you can
run on everything in the BaTLab, then you've written some fairly
cross-platform code.

I used to work for a company whose software ran under MacOS, Windows,
and roughly 25 different Unix variants. (Yes, there really used to be
that many Unixen.) Once you get your code compiling cleanly under two
dozen different compilers, then you can really say something about not
having any lurking undefined behaviors. I particularly remember that
our Data General box, running DG/UX, would emit compiler warnings about
things that nothing else complained about, and every one of those
warnings revealed a real problem that we were glad to find and fix. The
compiler was slow as molasses, but when it spoke to us ... we listened
closely.

In my experience what worked well was to have (1) diversity among
primary machines used by developers; (2) easy developer access to other
kinds of machines for testing; and (3) strong social enforcement that
says that we are a cross-platform shop, so if your code fails on any
supported platform, then your code is wrong, and "worked on my machine"
is not a legitimate excuse.

I guess I'm not really answering your question here, regarding developer
work flow. But perhaps this is a useful perspective anyway, to help you
see that platform heterogeneity can be a benefit, not just a hassle.
Good luck! In the words of my former employer's VP of engineering ...
"There is no such thing as portable code. There is merely code that has
been ported."

-- Ben