EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

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

Subject: Re: Problem with e_flex in base
From: Andrew Johnson <[email protected]>
To: Mark Rivers <[email protected]>
Cc: [email protected]
Date: Tue, 28 Feb 2006 17:17:22 -0600
Mark Rivers wrote:

I believe I used WinZip to extract the archive, rather than tar.

That at least explains where the line endings got changed.


I don't think I like your proposed solution for the following reasons:

- EPICS is supposed to build for multiple architectures from the same
source tree.  If I use WinZip to extract EPICS base it builds fine for
WIN32.  However, if I later decide I also want to build for Cygwin, I
can't use that same source tree.

If you try to build a tree that has DOS line endings using the SUNWspro compiler on Solaris, it does fail. Consider this C construct, which is used in various places in base:


#define macro \
	multi-line \
	macro being \
	defined here

The Solaris C preprocessor takes the first back-slash to be escaping the following <cr>, and the <lf> immediately following it to be the end of the macro definition. It also reports the following warning on every single #include line it sees:

warning: invalid white space character in directive

Thus it is not reasonable to expect *all* architectures to build from the exact same source tree.

- Even if I untar the source file with Cygwin tar, if I then use a
Windows text editor, such as Wordpad, to edit any .l file (in base or in
any application), e_flex fails.

Unless you configure Cygwin to use DOS line endings, which should fix the problem for *every* C program automatically since it modifies the behaviour of the C runtime library. Do you have some particular objection to doing that? I'm not a Cygwin/Windows user, so I don't know if there's a downside to it.


- Most, if not all, other EPICS code that reads ASCII files (.adl files,
.db files, .dbd files, etc.) are now tolerant of either type of line
terminator.  e_flex seems to be the exception.

GCC also seems to have bowed under pressure so it also accepts the above macro without complaint, even on Unix systems. I guess this is one of those "be liberal in what you accept" situations, so I'll commit the changes.


Flex is third party software and is pretty complex, written using itself. I believe that my changes are correct, but they will need to be tested.

- Andrew
--
There is no S in exprexxo.

References:
RE: Problem with e_flex in base Mark Rivers

Navigate by Date:
Prev: RE: Problem with e_flex in base Mark Rivers
Next: XYCOM XY566 Single Ended Mode with EPICS 3.14 and Power PC Simon Rees
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: Problem with e_flex in base Mark Rivers
Next: GPIB swap 1014D with 1014 Waggoner, Bill
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·