Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

#define SOL /* Compile as a shared object library */ #74

Closed
bemcdonnell opened this issue Aug 17, 2017 · 25 comments
Closed

#define SOL /* Compile as a shared object library */ #74

bemcdonnell opened this issue Aug 17, 2017 · 25 comments

Comments

@bemcdonnell
Copy link
Member

Issue Copied from USEPA/Stormwater-Management-Model

@bemcdonnell
Copy link
Member Author

Also reference issue #63

@bemcdonnell
Copy link
Member Author

@jmpmcmanus, I think we can get away with compiling a dylib and opposed to a formal Shared Object:

https://stackoverflow.com/questions/9688200/difference-between-shared-objects-so-static-libraries-a-and-dlls-so

@goanpeca
Copy link

@bemcdonnell I agree... that is what we are doing now anyway

@bemcdonnell
Copy link
Member Author

@goanpeca, I think it would be a good idea to remove that line from swmm5.c

@jmpmcmanus
Copy link

jmpmcmanus commented Aug 17, 2017 via email

@goanpeca
Copy link

@jmpmcmanus we are using conda and the conda infrastructure + cmake to do all our compilation.

Are you familiar with conda?

@bemcdonnell
Copy link
Member Author

@jmpmcmanus, there are a couple makesfiles available in the '_build' directory. I suggest editing one of them to add the flag to define DLL. This way we do not need to keep changing this in the code. If I remember right it is -D DLL (you should fact check me)?

makefile

@bemcdonnell
Copy link
Member Author

@goanpeca, just to be clear, my comment is relevant if @jmpmcmanus wants to build locally. If we want to move all builds to the web, conda is the best option as of today.

@bemcdonnell
Copy link
Member Author

The repo is also setup with CMAKE but I haven't testing this on Linux, personally.

@jmpmcmanus
Copy link

jmpmcmanus commented Aug 17, 2017 via email

@goanpeca
Copy link

@bemcdonnell I understand, but even then the suggested compilation should be using CMAKE, not those makefiles. I left them for reference, but I would consider them obsolete.

@jmpmcmanus actually if you install conda (via, anaconda or miniconda) then you can install conda-build and ran the build process on your local machine easily

  • Download install conda (via anaconda or miniconda)
  • Install conda build. $ conda install conda-build
  • Clone the SWMM repo
  • Run the build process $ conda-build conda.recipe
  • You should have now a conda package for lib-swmm, and inside it you can find the compiled DLLS.

@bemcdonnell
Copy link
Member Author

@goanpeca, can you provide that information in the wiki? I think it is very useful beyond this issue. Maybe a new page called Builds.md or building.md?

@goanpeca
Copy link

Sure can, please open an Issue and assign it to me?

@bemcdonnell
Copy link
Member Author

@goanpeca, I don't see inside the conda.recipe that it defines -DDLL (nor do I see this line in the CMake files). Am I missing something?

@goanpeca
Copy link

-DLLL ??? we make dylib on mac and so on linux with the current setup

@bemcdonnell
Copy link
Member Author

It's not the extension I'm commenting on. I'm talking about defining one of these inside the makefile instead of uncommenting/commenting them inside the code. In VS I have a flag to define DLL or CLE depending on my target. This can also be accomplished inside a linux makefile

swmm5.c

//#define CLE     /* Compile as a command line executable */
//#define SOL     /* Compile as a shared object library */
//#define DLL     /* Compile as a Windows DLL */

@bemcdonnell
Copy link
Member Author

//#define CLE     /* Compile as a command line executable */
//#define SOL     /* Compile as a shared object library */
//#define DLL     /* Compile as a Windows DLL */ 

Should change to "Dynamic Linking Library" instead of "Windows DLL" This should help with confusion

@samhatchett
Copy link

Maybe I'm not tracking the conversation well, but i think the preferred solution to specifying the compilation output would be by passing a flag to CMAKE - such as the standard BUILD_SHARED_LIBS. Although I'm not sure if this plays nice with conda.

@jmpmcmanus
Copy link

jmpmcmanus commented Aug 17, 2017 via email

@goanpeca
Copy link

@jmpmcmanus the pyswmm is not able currently to work correctly, cause this is a work in progress. The libswmm packages are compiled on the CI system and are meant to be used for dev only purposes. I was suggesting you build the library locally on your system with conda-build, and then extract the .so library and put it in the lib folder of pyswmm and seeing if that was working for you.

@bemcdonnell
Copy link
Member Author

@jmpmcmanus, if you got SWMM to compile, There is a subfolder in the pyswmm package

pyswmm\lib\linux

Place the .so in there and see if that works.

@bemcdonnell
Copy link
Member Author

@samhatchett, thanks for sharing the link. That seems to be the most standard way to implement this build. I have another issue raised to pull out the main entry point from swmm5.c much like you all did for EPANET.

@jmpmcmanus
Copy link

jmpmcmanus commented Aug 17, 2017 via email

@goanpeca
Copy link

@jmpmcmanus

I put them in the appropriate directories, and then ran run-swmm which worked

Great to hear that, the idea with conda, is that you can simply install that local compiled version (for develop SWMM) and then install pyswmm with conda and it should just work. We are a few weeks behind that workflow but we are almost there. Thanks for testing

@bemcdonnell
Copy link
Member Author

@jmpmcmanus, for pyswmm specific issues, let's continue those over at pyswmm on the issue you raised earlier:

pyswmm/pyswmm#114

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants