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: Mark Rivers <[email protected]>
To: 'Andrew Johnson' <[email protected]>, Michael Davidsaver <[email protected]>, Ralph Lange <[email protected]>, EPICS core-talk <[email protected]>
Date: Fri, 8 Dec 2017 19:45:37 +0000
Hi Andrew,

I just looked at the start of the current Windows EPICS 7 Jenkins build console output.  I see this:

C:\jenkins\win64-1\workspace\epics-master-windows\LIBRARIES\DLL\OS\win64>C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat x64 
'C:\Program' is not recognized as an internal or external command,
operable program or batch file.

So it looks to me like it did not execute vcvarsall.bat for that version of Visual Studio, so it is probably still using the old default version of Visual Studio?

I think you are missing quotes in the path name.  My batch file for 2017 has this:

"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build\vcvarsall.bat" amd64

Mark


> -----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

Replies:
Re: moving initHooks into libCom Andrew Johnson
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

Navigate by Date:
Prev: Re: moving initHooks into libCom Andrew Johnson
Next: Re: moving initHooks into libCom Andrew Johnson
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 Andrew Johnson
Next: Re: moving initHooks into libCom Andrew Johnson
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 ·