Experimental Physics and
Industrial Control System

On March 9th I committed base/configure file changes to embed the new
Visual c++ 2005 *.manifest files into a library or executable. The binary
install rule in RULES_BUILD will no longer have the problem causing "$<*"
for installation of the *.manifest files. These changes will appear in the
next R3.14 base release.

Hi Dale,

this is an error I found and reported two months ago (see attached mails for analysis, workaround and Janet's reply).
I don't know the current status, but I created Mantis Bug Report 244 now to make sure the bug is visible and searchable. (I really should have created the Mantis entry back then.)

Sorry for the inconveniences,
Ralph

Dale L. Brewe wrote:

I'm having a bit of a problem building epics base 3.14.8.2 w/ the win32-x86 platform. The build progresses ok for awhile til I get output from gnumake (3.78.1 or 3.80) that ends w/
[...]

------------------------------------------------------------------------

Subject:
Re: 3.14.8 / cygwin dependency
From:
Ralph Lange <[email protected]>
Date:
Mon, 23 Jan 2006 15:47:19 +0100
To:
Janet Anderson <[email protected]>

To:
Janet Anderson <[email protected]>
CC:
EPICS Core Talk <[email protected]>

Hi Janet,

I found the change that broke the non-cygwin build:

In RULES_BUILD 1.88.2.14 the line to install binaries was changed from
  @$(INSTALL_PRODUCT) -d -m 555 $< $(INSTALL_BIN)
to
  ifdef WIN32
      @$(INSTALL_PRODUCT) -d -m 555 $<* $(INSTALL_BIN)
  else
      @$(INSTALL_PRODUCT) -d -m 555 $< $(INSTALL_BIN)
  endif

Immediately afterwards the wildcard was taken back for BORLAND compilations.
The problem is that the standard Windows shell - or whatever make uses to call programs on non-cygnus systems - does not allow wildcards in this place. Changing the "$<*" to "$(wildcard $<*)" lets make do the wildcard job, which should be the better option, anyway.

What exactly were you trying to "catch" with that wildcard? For my Microsoft non-cygnus system I actually can't think of any other files that would be matched by it.

I didn't commit any changes to CVS as I wasn't sure about the usefulness of that wildcard.
So - if we need the wildcard, please change it as shown above, which will work everywhere. If we don't need the wildcard, going back to the traditional line is fine with me.

Cheers,
Ralph

------------------------------------------------------------------------

Subject:
Re: 3.14.8 / cygwin dependency
From:
Janet Anderson <[email protected]>
Date:
Wed, 25 Jan 2006 13:21:45 -0600
To:
Ralph Lange <[email protected]>, Hill Jeff <[email protected]>

To:
Ralph Lange <[email protected]>, Hill Jeff <[email protected]>

The command line wildcard was introduced 2 days before R3.14.8 was released
as a quick fix for EPICS base bug # 231. See the bug notes for details.
The new Microsoft Visual c++ 2005 linker creates a .manifest file with each
executable and library (e.g. ca.dll ca.dll.manifest). It seems that this file
needs to be installed in the same directory as the executable/dll. This was a
temporary change I committed until we better understand how manifest files are
used and whether or not we need new CONFIG files for the new compiler. Ken Evans
is now looking into manifests to better understand them and to solve problems
we have with manifests for java jni libraries. Using a wildcard function seems
like a better way to implement the quick fix.

Janet

Ralph Lange wrote:

Hi -

I was thinking and talking about this issue a bit more:
Now I would say it's generally bad to use wildcards for what is done within make target chains, as this introduces hidden dependencies that make never has a chance to know about and resolve correctly.

Janet (or Jeff): What was this wildcard introduced for? As it's not for the Borland (by ifdef) and not for the Microsoft (by my experience), it can only affect the MinGW or Cygnus compilers. Are there other files generated apart from the target dll or exe? Or does the compiler name the target dll or exe different from the usual make target name? Wouldn't it be possible and more appropriate to add targets or change the target name in that case?

Cheers,
Ralph

Jeff Hill wrote:

Thanks Rlaph.
Actually surprised that I havent seen this here.

Jeff

-----Original Message-----
From: Ralph Lange [mailto:[email protected]] Sent: Monday, January 23, 2006 7:47 AM
To: Janet Anderson
Cc: EPICS Core Talk
Subject: Re: 3.14.8 / cygwin dependency


Hi Janet,

I found the change that broke the non-cygwin build:

In RULES_BUILD 1.88.2.14 the line to install binaries was changed from
  @$(INSTALL_PRODUCT) -d -m 555 $< $(INSTALL_BIN)
to
  ifdef WIN32
      @$(INSTALL_PRODUCT) -d -m 555 $<* $(INSTALL_BIN)
  else
      @$(INSTALL_PRODUCT) -d -m 555 $< $(INSTALL_BIN)
  endif

Immediately afterwards the wildcard was taken back for BORLAND compilations. The problem is that the standard Windows shell - or whatever make uses to call programs on non-cygnus systems - does not allow wildcards in this place. Changing the "$<*" to "$(wildcard $<*)" lets make do the wildcard job, which should be the better option, anyway.

What exactly were you trying to "catch" with that wildcard? For my Microsoft non-cygnus system I actually can't think of any other files that would be matched by it.

I didn't commit any changes to CVS as I wasn't sure about the usefulness of that wildcard.
So - if we need the wildcard, please change it as shown above, which will work everywhere. If we don't need the wildcard, going back to the traditional line is fine with me.

Cheers,
Ralph

References:

problem building 3.14.8.2 with win32-x86 Dale L. Brewe

Re: problem building 3.14.8.2 with win32-x86 Ralph Lange

Navigate by Date:

Prev: RE: building 3.14.8.2 on win32-x86 Jeff Hill

Next: Was this EPICS? Lawrence T. Hoff

Index: 1994  1995  1996  1997  1998  1999  2000  2001  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: problem building 3.14.8.2 with win32-x86 Ralph Lange

Next: Fwd: problem building 3.14.8.2 with win32-x86 Dale L. Brewe

Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <2006>  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024