Re: If you wanted to distribute a dll
- Posted by xecronix Sep 14, 2015
- 1605 views
I see only two options here:
- place all Euphoria-specific shared libraries in the BIN dirctory and the wrapper files in the INCLUDE directory
- optionally, place the wrapper files within a new directory (e.g. "CURL")
I like this idea but not as much as the putting the dll in a "ext" directory included with the library. The idea is it should be as easy as possible for developers using my library to include the lib in the application they write.
The Only 2 concerns I have with your proposed approach is
- it seems to muddy the Euphoria bin directory which presents some challenges when upgrading from version to version of Euphoria.
- it doesn't allow the user to have more than one version of the same wrapper. IE version 1.0 and version 2.0 of the wrapper for the guitar lib I wrote for the recent mini guide.
I would consider point one more of a nuisance than a real problem. But point 2 feels like a real problem. On linux this is solved with shared object naming conventions and symlinks. This concept doesn't really port well to Windows. Windows solves this problem by loading dll xyz.dll based on where it exists on the file system. This doesn't port well to Linux but is easily duplicated programatically.
- place the shared libraries and include files directly within your application directory
I can't agree with you more on this point. Say you write an application that uses my library or my wrapper. To bundle my wrapper/lib all you should need to do is place the wrapper directory in the include_paths and you're done. That's my goal anyway.
The key takeaway here is, an application should not be looking all over the place for its shared libraries. One could get into trouble when encountering the wrong (i.e. incompatible) version of a shared library. This is especially true when moving from one distro to the next and across major generations of a distro with grossly disparate libraries.
If we agree that all Euphoria shared libraries go into one of two known safe locations, then things should work out well. If we start venturing into the realm of system-wide shared libraries, then we have a problem. One caveat to this is if the shared library wrapper is using a distro-provided library, like CURL or ZLIB.
Absolutely correct. I feel like there is only 1 safe place to put the dll most of the time. And while I'm super flexible on what that place is named or where it exists in the file system hierarchy that place should be part of the wrapper directory structure. Other "reasonable places" are an attempt to not go against the grain. Developers and users are used to putting dlls in certain places and expecting things to just work.
All that being said, this is a problem that is best solved by some sort of package management system, which could install or provide dependencies as needed depending on the system. We need to download CURL or ZLIB on Windows, but we'll use the system libraries on Linux.
I agree again. This is actually a goal of mine. I'm working on porting the Ruby Gem concept to Euphoria. You can see some of my notes on the topic on my OpenEuphoria wiki page if you'd like. It's called the EuDrop Project. The project is very raw at the moment. I'm still defining scope. But there is a wiki page for it if you'd like to peek.
Funny how things turn out sometimes. euLibCurl.e is actually the wrapper I'm looking at now and is the topic of the next part of Complete Guide to Using DLLs in OpenEuphoria series.
I'm glad we're getting this chance to discuss this now.
