search

OpenWaterAnalytics / EPANET

The Water Distribution System Hydraulic and Water Quality Analysis Toolkit
MIT License
279 stars 204 forks source link

standardize build files #38

Closed samhatchett closed 5 years ago

samhatchett commented 8 years ago

a question: how many (and which) build environments should we support within this project? so far, we have various build files for MSVS, CMake, MingW, Xcode, and Make. should this be simplified for easier maintenance? or are there enough interested parties that can maintain all these configurations? I understand that CMake was invented to try to handle this situation exactly...

samhatchett commented 8 years ago

related to #15

eladsal commented 8 years ago

I'm going to support the Windows build files here. I think this is what you refer to as Make.

samhatchett commented 8 years ago

Make is a Linux tool. I did forget to post the bat files you set up though. Have you looked at cmake? It will auto-generate build files for almost any tool chain.

michaeltryby commented 8 years ago

@samhatchett I'll second CMake. It seems like the right tool to help maintain native build workflows on multiple platforms.

samhatchett commented 8 years ago

CMake might be considered "yet another dependency" or hurdle since you have to download the tool to generate build files for your platform -- this sort of thing tends to be somewhat controversial with the epanet project. Of course, a simple user who downloads the pre-built command-line / library package of epanet for their platform will (as always) have no external deps.

Still, if you are actually compiling software, is this too much to ask? You would have to already have some sort of build environment set up at minimum, which means you sort of know how to use a computer...

We don't have to have this fight right now, but I would support the idea of eventually moving all build configurations to a single master CMake file, and perhaps keep an archive of the auto-generated build files for multiple platforms as a convenience.

eladsal commented 8 years ago

I agree that we should aim for a one build script. If CMake is the best option then we should go for it.

Let us mark this for 2.2 and work on #15 for 2.1 with separate scripts. The ones @eldemet and me worked on is used on Windows machines with VBA\VB6\C#\VB.NET\Matlab (these I know of).

goanpeca commented 8 years ago

CMake might be considered "yet another dependency" or hurdle since you have to download the tool to generate build files for your platform -- this sort of thing tends to be somewhat controversial with the epanet project. Of course, a simple user who downloads the pre-built command-line / library package of epanet for their platform will (as always) have no external deps.

When using conda conda will take care of this, as CMake is defined as a build dependency and the corresponding conda package is downloaded. Installing conda is easy... downloading (anaconda from here) or miniconda from here and then conda install open-epanet -c openwateranalytics. For building is the same but the conda build command is used, and then running the build command. But the idea is that all build of packages is automatic with CI (for all OSs) when a new release is tagged on github.

If users are already doing python work (which seems to be the common case for OS data science/research (engineering needs to catch up...), then it is very likely they are using anaconda already, specially if they are on windows.

Still, if you are actually compiling software, is this too much to ask? You would have to already have some sort of build environment set up at minimum, which means you sort of know how to use a computer... We don't have to have this fight right now, but I would support the idea of eventually moving all build configurations to a single master CMake file, and perhaps keep an archive of the auto-generated build files for multiple platforms as a convenience.

I will be using CMake only for creating conda packages (as part of #78), I think CMake is the best choice also for cross-platform build.

michaeltryby commented 6 years ago

This issue was opened almost three years ago. Within the EPANET and SWMM projects CMake is now used to automate the build and unit tests on CI. Personally, I use it to build locally from the command prompt and to generate solution files for Visual Studio when I want to use the IDE. Learning CMake was a total PITA, once configured, however, it works great! Overall it was a good choice for the project.

If I'm not mistaken the original intent of this Issue was to standardize the project on a build system. I would argue that OWA EPANET has become a CMake centric project. Coercing our fellow developers to adopt CMake would do more harm than good. Those developers maintaining their own build script are welcome to come out of the cold whenever they are ready! :smile: