Experimental Physics and
Industrial Control System

Benjamin Franksen <[email protected]> · Tue, 4 Nov 2014 14:08:17 +0100

On Tuesday 04 November 2014 11:49:46 [email protected] wrote:
> From: Benjamin Franksen
> [mailto:[email protected]]
> > On Monday 03 November 2014 12:34:27 [email protected]
> > wrote:
>
> > > The workaround you have is just fine, and in fact you could
> > > instead
> > > get away with removing the -Werror from the list in setup.py.
> > > I've
> > > always tried to eliminate as many warnings as possible from my
> > > code,
> > > but maybe I should somehow remove the -Werror from the released
> > > version.
> >
> >
> > Definitely. The next version of gcc might issue warnings for things
> > you
 don't imagine could cause a warning... I guess it is
> > impossible to write
> > C code that is and will be free of compiler warnings for all times,
> > no
 matter which compiler you are using, and no matter how closely
> > you follow the C standard to the letter. BTW, -Werror is gcc
> > specific, what if someone wants to use a different compiler?
>
>
> I don't claim to be cross platform.  clang also recognises -Werror and
> the handful of slightly odd gcc extensions that I use.  If somewhat
> wants to use a different compiler and is successful then I'm happy to
> look at patches to the build process.
>
> Can you suggest a clean mechanism for removing -Werror from the build?
>  My problem is that we're looking at a source release here made
> directly from the source tree, quite probably a tagged checkout from
> somewhere like https://github.com/Araneidae/cothread, and thus it's
> exactly the same code that I'm developing with.

I have been facing similar issues with the sequencer. In my experience,
properly releasing software requires that you do development on a
separate branch (and possibly more than one); then pull changes from the
development branch to the main trunk as soon as things are working and
tested. While doing so, you can chose to select only those changes you
actually want to have in the release. To make this easier, I mark
changes I want only for development in the patch comment e.g. "DEVEL
ONLY extra warnings for gcc". Note, I am using Darcs for version
control, where cherry-picking changes is a very natural way to do
things, so your mileage may vary. BTW, another thing I usually do before
making a release is to make Darcs list all the changes since the most
recent tag; this makes nice raw material for release notes and it helps
against forgetting to mention something important.

> I have to confess that I don't feel very confident at creating
> external releases.  At Diamond we have our own very strange internal
> build process and environment, and it gets quite difficult to make
> releases that work properly away from this environment.

I fear this is quite a typical situation. The only solution I know is to
bite the bullet and regularly build on a separate machine that does not
have all the extra (read: special Diamond) stuff installed, maybe even
do most of the development there. At least do so when preparing a new
release.

You might also want to ask the EPICS V4 developers (epics-pvdata-
[email protected]) how they manage these issues: if I remember
correctly they support Python bindings to their APIs and their build
system (for the C++ version) uses the rules from EPICS base.

Cheers
Ben
--
"Make it so they have to reboot after every typo." ― Scott Adams

________________________________

Helmholtz-Zentrum Berlin für Materialien und Energie GmbH

Mitglied der Hermann von Helmholtz-Gemeinschaft Deutscher Forschungszentren e.V.

Aufsichtsrat: Vorsitzender Prof. Dr. Dr. h.c. mult. Joachim Treusch, stv. Vorsitzende Dr. Beatrix Vierkorn-Rudolph
Geschäftsführung: Prof. Dr. Anke Rita Kaysser-Pyzalla, Thomas Frederking

Sitz Berlin, AG Charlottenburg, 89 HRB 5583

Postadresse:
Hahn-Meitner-Platz 1
D-14109 Berlin

http://www.helmholtz-berlin.de

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System