policy regarding Makefiles and their output targets.
Used to create library and executable file names that included
the compiler (e.g., *_gcc_*) and the SVN rev (*_309_*). This
was to allow development along the trunk while keeping clean track
of the SVN versions that objects were made from.
Maybe a good idea in part, but no longer. It collapsed under its
own complexity. The need to keep track of all the specific
file names became more burdensome that the need to keep track
of which source actually built an object.
As of now, Makefiles produce unadorned file names:
Linux:
lib<name>.so
<name>
Cygwin:
cyg<name>.dll
cyg<name>.exe
libcyg<name>.dll.a
MSVC:
<name>.dll
<name>.exe
<name>.lib
MinGW:
Same as MSVC
Darwin:
Don't know about this, but I think they already were produced
with just dy extensions
Under this scheme MinGW looks just like MSVC, but I guess that's
the whole point...
git-svn-id: https://epanet.svn.sourceforge.net/svnroot/epanet/BASE/trunk@314 c320cabd-cc23-0410-96d8-e60fbf53ed7f
---
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
