---
Modified erd/src/erdinternal.c because Cygwin appears to define
fpos_t as a long (it is not a structure, as with Linux)
BASE/MSX/ERD/WDSSIM
-------------------
Cygwin makefiles had been building code using MingW. This was
confusing, as one might expect such makefiles to produce
cygwin DLLs and executables and not native windows (i.e. MingW)
DLLs and executables.
Also, this was a problem because sometimes one would prefer
to have Cygwin DLLs because one wants to produce Cygwin
executables using them. Practically, it can be more
convenient to produce Cygwin executables for a Windows
target machine, just because the Cygwin environment is closer
to a complete Unix environment. In fact the motivation for this
was the need to build WDSSim for a windows target, and this led
to annoying complications with libxml2 libraries and include
files when trying to build everything as native Windows using
MingW.
Now, build/Cygwin makefiles are producing Cygwin DLLs/executables
and NOT native windows DLLs/executables. The old Cygwin-MingW
makefiles have been retained, but placed in new MingW build
subdirectories for those cases when one really wants to use MingW
to build for a native windows target.
FILE NAME CONVENTIONS
---------------------
All this is terribly confusing, and we wish for a plain old
Linux environment. With regard to file and library names,
there is significant potential to confuse things. Accordingly
we have defined the following standard naming convention that
eventually everything in ENGCVS should use.
If one has a library called "mylib", the names of the various
files should be the following, BY CONVENTION (i.e. they don't
have to be these names, but if they aren't, then you'll just
confuse the heck out of the rest of us).
CYGWIN DLL (shared library)
cygmylib.dll (DLL) (note 'cyg' prefix indicates it is a cygwin object)
cygmylib.def (DEF)
libcygmylib.dll.a (import lib) (note '.dll' indicates it is an import library pointing to a DLL)
CYGWIN ARCHIVE
libcygmylib.a (object archive) (note the absence of '.dll' indicates it is an object archive an not a DLL import lib)
MINGW DLL (shared library)
mylib.dll (DLL) (note this is a native windows DLL, and the absence of 'cyg' shows that)
mylib.def (DEF)
libmylib.dll.a (gcc import lib)
mylib.lib (LIB) (msvc import lib, pointing to same DLL - produced using msvc LIB.EXE)
MINGW ARCHIVE
libmylib.a (object archive)
LINUX SO (shared library)
libmylib.so (SO - shared object library, Linux analogue to windows DLL)
(No DEF or import library required)
LINUX ARCHIVE
libmylib.a (object archive)
Note how these names uniquely specify the target (cygwin, windows, Linux) as well as the
file type (DLL, SO, DEF, import lib, object archive). Or at least mostly uniquely - note
that the object archive is the same name on Linux and under MinGW. This shouldn't be
problem since Linux object archives shouldn't ever be present on Windows machines, and
vice-versa. And if they are (by mistake/accident), the codes won't link or run so there
will be definitive identification of the error.
Finally, for an executable code "mycommand" we have the following
CONVENTION:
mycommand.exe (Windows/MingW or Windows/MSVC)
cygmycommand.exe (Windows/Cygwin)
mycommand (Linux)
git-svn-id: https://epanet.svn.sourceforge.net/svnroot/epanet/BASE/trunk@221 c320cabd-cc23-0410-96d8-e60fbf53ed7f
because of changes in epanet.c at 2.00.12.
epanet.c changed to comment out definition of DLL, allowing DLL, SOL, or
CLE to be defined at compilation.
git-svn-id: https://epanet.svn.sourceforge.net/svnroot/epanet/BASE/trunk@220 c320cabd-cc23-0410-96d8-e60fbf53ed7f
