2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 <2014> 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 | Index | 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 <2014> 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 |
<== Date ==> | <== Thread ==> |
---|
Subject: | RE: EPICS base 3.15.0.2 |
From: | "Heesterman, Peter J" <[email protected]> |
To: | "Andrew Johnson" <[email protected]> |
Cc: | EPICS core-talk <[email protected]>, [email protected] |
Date: | Mon, 3 Nov 2014 12:38:37 -0000 |
Hi Andrew,
Hope you had a good weekend.
I have resolved this problem, with the help of the Process Monitor tool from SysInternals.
Indirectly, it is a consequence of my use of VS project build.
I have a VS workspace EPICS.sln (or Solution, in MS parlance), that resides in my directory D:\Epics.
This is my uber-workspace that builds all of the EPICS code I've looked at.
(similarly, I have a workspace base.sln in D:\EPICS\base that builds only base.
And D:\EPICS\asyn\asyn.sln that builds only asyn and its dependencies, that are in base.
And so on.)
When I use the EPICS.sln build, header files, et al, are copied into the directory D:\EPICS\include.
The base makefile build should copy files into, and expect them to be in, D:\EPICS\base\include.
In the Process Monitor log, I noticed the make file build process referenced both D:\EPICS\base\include (as would be expected) and D:\EPICS\include (which is the wrong path for this build!).
Finding e.g. flex.skel.static in D:\EPICS\include, it saw apparently no need to copy the file into D:\EPICS\base\include.
I deleted D:\EPICS\include, and then used the makefile build normally.
>> The 3.15.0.2 version of base.dbd does include menuGlobal.dbd
No it doesn't!
I attach your version.
>> Win32.bat.
The only significant difference I can see between your version of this file and mine is that your version sets an explicit path to G:\epics\base\bin\%EPICS_HOST_ARCH%, where G:\ is presumably a network drive that you're using.
Please have a look at my version (attached).
Cheers,
Peter.
-----Original Message-----
From: Andrew Johnson [mailto:[email protected]]
Sent: 31 October 2014 23:08
To: Heesterman, Peter
Cc: [email protected]; EPICS core-talk
Subject: Re: EPICS base 3.15.0.2
Hi Peter,
On 10/31/2014 01:16 PM, Heesterman, Peter J wrote:
> My install process has been to delete my pre-existing 'base'
> directory, copy your download in its place, and then recover my
> non-downloaded files (i.e., principally my VS project files) over the
> top, from my source control server.
That seems perfectly reasonable.
> I have carefully compared - windiff - my install directory with your
> raw download directory.
>
> Changed files are:
>
> Due only to the patch you sent me earlier:
> .\src\libcom\flex\makefile
> .\src\libcom\flex\rules
I don't now believe those changes should be necessary, but they won't cause any harm.
> For the reasons previously discussed:
> .\src\libcom\misc\epicstypes.h
Accepted.
> .\src\std\softioc\base.dbd
The 3.15.0.2 version of base.dbd does include menuGlobal.dbd, so I don't follow what you've done there but it wouldn't explain the build issue at all anyway.
> I have customised Win32.bat - I believe correctly - to suit my build environment and paths, and have retained my version.
> It has not changed from my builds prior to this download.
>
>>> Make -v
> I note that it says
> This program built for i386-pc-mingw32
>
> I'm using GnuWin32, not mingw, for my build.
That's probably the same as mine then, which is the GnuWin32 version:
> D:\epics\mirror-3.15>make -v
> GNU Make 3.81
> Copyright (C) 2006 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.
> There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
> PARTICULAR PURPOSE.
>
> This program built for i386-pc-mingw32
> Does this make sense?
It doesn't sound like you're doing anything wrong, but I don't understand why your build behaves so differently to everybody else's.
You shouldn't have to copy files into the .\include directory by hand, that's a standard functionality that the build system performs.
The only thing I can think is that it might be something to do with your VS project files or build, although that seems unlikely. I'm a bit stumped at this point.
Could you run 'make distclean' at the top of the Base tree and then log the output from 'make' and send me the result to look at. The distclean will delete all of the build and install files, including anything that you've copied by hand, so I can see exactly what you get from a clean build.
- Andrew
--
People everywhere confuse what they read in newspapers with news.
-- A. J. Liebling
Attachment:
base.dbd
Description: base.dbd
Attachment:
win32.ba_
Description: win32.ba_