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
- Replies:
- RE: moving initHooks into libCom Mark Rivers
- RE: moving initHooks into libCom Mark Rivers
- References:
- moving initHooks into libCom Michael Davidsaver
- Re: moving initHooks into libCom Andrew Johnson
- Re: moving initHooks into libCom Michael Davidsaver
- 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
<2017>
2018
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
<2017>
2018
2019
2020
2021
2022
2023
2024
|