EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <20172018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <20172018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: moving initHooks into libCom
From: Andrew Johnson <[email protected]>
To: Mark Rivers <[email protected]>, Michael Davidsaver <[email protected]>, Ralph Lange <[email protected]>, EPICS core-talk <[email protected]>
Date: Fri, 8 Dec 2017 13:43:16 -0600
On 12/08/2017 01:27 PM, Mark Rivers wrote:
>> We do have MS Visual Studio 14.0
> 
> Do you mean Visual C++ 2015 (also known as Visual C++ 14.0)?
> 
> If so that version failed for me.

I didn't do the install so I only know what the install path to it is,
but that sounds right. It doesn't seem to have failed the DLL builds
with that compiler at all though (there is something very strange about
the test results displayed in the build log, but no tests actually failed).

- Andrew

>> -----Original Message-----
>> From: [email protected] [mailto:[email protected]] On Behalf
>> Of Andrew Johnson
>> Sent: Friday, December 08, 2017 1:19 PM
>> To: Michael Davidsaver; Ralph Lange; EPICS core-talk
>> Subject: Re: moving initHooks into libCom
>>
>> On 12/08/2017 12:20 PM, Michael Davidsaver wrote:
>>> On 12/08/2017 12:24 PM, Andrew Johnson wrote:
>>>> Hi Michael,
>>>>
>>>> Assuming you're intending it to be merged *after* the 7.0.1 release then
>>>> yes, please go ahead and work on it.
>>>
>>> "Before or after" is my question.  Before would let me eliminate libpvAccessIOC
>>> in this release.  This has never been a concern for me, but was for Ralph.
>>
>> I would have liked to eliminate that library, but I think it's too late
>> now. The EPICS_BASE_PVA_CORE_LIBS variable should probably exclude the
>> pvAccessIOC library, and pva2pva could export EPICS_BASE_PVA_IOC_LIBS
>> say, which should include both pvAccessIOC and qsrv. That change I would
>> still accept. There might need to be an adjustment to the pvDatabase
>> module which is now using that variable and was previously linking
>> against pvAccessIOC, but I don't know if it actually needs it or not.
>>
>>>> However I would prefer that you fix the MSVC compiling issues that have
>>>> been reported in pva2pva first, since we should really fix them *before*
>>>> the final release which is due out on Tuesday.
>>>
>>> I'm fighting limited time, and internet access, this week.
>>> Also the usual problem that I don't have access to MSVC!
>>>
>>> How would you like me to approach this?
>>> I can't say that I relish spending time on appveyer config,
>>> but if APS jenkins doesn't show the failure, then I guess
>>> this is my only option.
>>
>> Mark Rivers also responded
>>> How hard would it be to upgrade the APS Jenkins server from 2010 to 2017
>>> Community?  I installed 2017 on my machine this week and it was pretty
>>> quick and painless.
>>
>> I have less than 12 working hours left until our telecon on Tuesday
>> morning when we'll start the final release, and I promised our IT group
>> I would continue working on moving the APS EPICS website to a new
>> web-server, so I'm running out of time myself.
>>
>> We do have MS Visual Studio 14.0 already installed on our Windows build
>> agent so I just adjusted the APS Jenkins epics-master-windows job to use
>> that instead of 2010 and triggered a rebuild, which seems to be running.
>> This job does update the submodules to the git tip, but it will only
>> check hourly and trigger automatically when the core/master branch is
>> updated so it will be faster to email me to run another build (use my
>> gmail if you're still working on it over the weekend).
>>
>>> Michael, if you have a pretty good idea how to fix it I could test
>>> compiling on 2015 and 2017, either via a git branch or just e-mail.  So
>>> far the problem just seems to be 1 file.
>>
>> It's probably worth testing those too if you can spare the time, maybe
>> after Michael has fixed the build with 14.0 (if it fails!).
>>
>> Thanks guys,
>>
>> - Andrew
>>
>> --
>> Arguing for surveillance because you have nothing to hide is no
>> different than making the claim, "I don't care about freedom of
>> speech because I have nothing to say." -- Edward Snowdon

-- 
Arguing for surveillance because you have nothing to hide is no
different than making the claim, "I don't care about freedom of
speech because I have nothing to say." -- Edward Snowdon

References:
moving initHooks into libCom Michael Davidsaver
Re: moving initHooks into libCom Andrew Johnson
Re: moving initHooks into libCom Michael Davidsaver
Re: moving initHooks into libCom Andrew Johnson
RE: moving initHooks into libCom Mark Rivers

Navigate by Date:
Prev: RE: moving initHooks into libCom Mark Rivers
Next: RE: moving initHooks into libCom Mark Rivers
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <20172018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: moving initHooks into libCom Mark Rivers
Next: RE: moving initHooks into libCom Mark Rivers
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <20172018  2019  2020  2021  2022  2023  2024 
ANJ, 21 Dec 2017 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·