parity with OWA root 2.00.12
remove CRT secure def for full OWA parity
Commit the EPANET2.00.12 to trunk, the changes are summarized at \EPANET\BASE\trunk\doc\changes.txt.

git-svn-id: https://epanet.svn.sourceforge.net/svnroot/epanet/BASE/trunk@95 c320cabd-cc23-0410-96d8-e60fbf53ed7f
A big that exists only in 2.00.12 is fixed. It is at function ENgetnodevalue for EN_SOURCEQUAL. A break statement rather than return should correspond to case.

git-svn-id: https://epanet.svn.sourceforge.net/svnroot/epanet/BASE/trunk@112 c320cabd-cc23-0410-96d8-e60fbf53ed7f
Makefile changed to build executable using all *.o instead of using DLL,
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
ERD
---
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
Removed existing MSVC epanet solution/project files, making room for new structure


git-svn-id: https://epanet.svn.sourceforge.net/svnroot/epanet/BASE/trunk@288 c320cabd-cc23-0410-96d8-e60fbf53ed7f
Modified epanet/base build/MSVC structure to include just sln and vcproj files for 
vs2008.



git-svn-id: https://epanet.svn.sourceforge.net/svnroot/epanet/BASE/trunk@291 c320cabd-cc23-0410-96d8-e60fbf53ed7f
Changed EPANET makefiles to use -O3 optimization level.


git-svn-id: https://epanet.svn.sourceforge.net/svnroot/epanet/BASE/trunk@303 c320cabd-cc23-0410-96d8-e60fbf53ed7f
After much thought and deliberation... a change in EPANET repo
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
update vc project file for epanet dll


git-svn-id: https://epanet.svn.sourceforge.net/svnroot/epanet/BASE/trunk@330 c320cabd-cc23-0410-96d8-e60fbf53ed7f
mac build files directory


git-svn-id: https://epanet.svn.sourceforge.net/svnroot/epanet/BASE/trunk@337 c320cabd-cc23-0410-96d8-e60fbf53ed7f
adding mac build files.  


git-svn-id: https://epanet.svn.sourceforge.net/svnroot/epanet/BASE/trunk@338 c320cabd-cc23-0410-96d8-e60fbf53ed7f
woops - removing intermediate files?



git-svn-id: https://epanet.svn.sourceforge.net/svnroot/epanet/BASE/trunk@339 c320cabd-cc23-0410-96d8-e60fbf53ed7f
intermediate files


git-svn-id: https://epanet.svn.sourceforge.net/svnroot/epanet/BASE/trunk@340 c320cabd-cc23-0410-96d8-e60fbf53ed7f
more intermediates.


git-svn-id: https://epanet.svn.sourceforge.net/svnroot/epanet/BASE/trunk@341 c320cabd-cc23-0410-96d8-e60fbf53ed7f
change project root.  this is mostly a test of scm.

git-svn-id: https://epanet.svn.sourceforge.net/svnroot/epanet/BASE/trunk@342 c320cabd-cc23-0410-96d8-e60fbf53ed7f
changed old RTX to "KF-DAL", the Kalman Filter Demand Allocation Library



git-svn-id: https://epanet.svn.sourceforge.net/svnroot/epanet/BASE/trunk@348 c320cabd-cc23-0410-96d8-e60fbf53ed7f
attempting to roll back to a working version

git-svn-id: https://epanet.svn.sourceforge.net/svnroot/epanet/BASE/trunk@375 c320cabd-cc23-0410-96d8-e60fbf53ed7f
fixing epanet repository

git-svn-id: https://epanet.svn.sourceforge.net/svnroot/epanet/BASE/trunk@376 c320cabd-cc23-0410-96d8-e60fbf53ed7f