Re: Unable to build support modules on Windows, with base 3.15.2

["J. Lewis Muir" <jlmuir@imca-cat.org>]

On 9/24/15 8:55 AM, Kevin Peterson wrote:
> On 9/16/15 3:46 PM, J. Lewis Muir wrote:
>> Hi, Mark.
>>
>> Andrew has such a web page for EPICS Base at:
>>
>> http://www.aps.anl.gov/epics/base/win32.php
>
> One of the problems with that web page is that you can read all of it
> and still not know which version of Visual Studio you should use to
> build on Windows.  It contains references to three different versions
> of Visual Studio:
>
> Visual Studio 2010 Express edition
> Visual Studio 2012 Express edition
> Visual Studio 2013 Express edition

Hi, Kevin.

I can see your point.  However, I'd say it's rather lame to say that
you have to use a specific version of a compiler to build on Windows.
(If I'm already using Visual Studio 2012 Express and it would work, I
certainly don't want to have to install 2010 Express just to build EPICS
Base.)  I think most people would expect a list of supported compilers.
So, I could agree that listing which versions of Visual Studio are
supported (or known to work) would be nice.

> The "Microsoft Visual Studio/C++ Express" download link contains a
> link to download Visual Studio Community 2015, which will only build
> base-3.14.12.5 if you know/remember to apply a patch from the known
> problems page.

This is a separate problem: EPICS Base is a software project that
doesn't make patch releases; it instead opts to provide a set of patches
against the latest stable release somewhere.  I disagree with this
approach.  Invariably people download the latest stable release not
realizing that it has problems that the developers already know about
and have already fixed!  To get the *real* stable release, you have to
find and apply additional patches.  This comes up fairly frequently
in my view.  EPICS Base does this, the motor module does this, and
StreamDevice does it too.

I assume the process of making a new release is automated, so time or
difficulty of making a new release shouldn't be the issue.  If the issue
is that the developers feel they haven't had a chance to test a fix,
I don't really agree with making a patch available that they haven't
tested.  If they have tested the patch, then I don't see why it can't go
into a patch release.  If the developers are worried about not having
wide testing of a patch and potentially introducing something that will
break other installs, I say two things.  One, I end up deploying all
the patches anyway because I don't want to have to deal with figuring
out which patches might affect me.  Two, a site that is very sensitive
to any change will just stay at their current release, upgrading to
the next patch release when they are ready.  I see no advantages, only
disadvantages, to providing a known problems page with patches over just
making a new patch release.

> If you succeed at building base, you'll encounter more problems when
> you try to build other EPICS modules.

Which problems are these?  If a certain compiler does not build
EPICS software correctly, it would be good to note that compiler as
unsupported on Andrew's page.

Regards,

Lewis