OpenEuphoria

1. If you wanted to distribute a dll

• Posted by xecronix Sep 12, 2015
• 1713 views

If you wrote a DLL or wrapped a DLL for other Euphoria developers to use, where would you expect the DLL to reside on the target machine? For example, say you wrapped libcurl and wanted to distribute the DLL along with your curl.e file. That way you could be sure that the user of your wrapper is using the correct version of the DLL you wrapped.

Some Possible locations:

• Wherever DLLs are located normally on the system. The problem with this solution that the user may already have a version of the DLL and that version is not 100% compatible with your wrapper. Or later he installs a version of the DLL that causes instability. The benefit is if you didn't write the code for the DLL or someone else is maintaining it you wont need to distribute bug fixes.

• Wherever Euphoria is installed. For example, by default Euphoria installed on my system in /usr/local/share/euphoria. So a good place to put the DLL might be /usr/local/share/euphoria/bin

• Wherever your wrapper is installed. I like this idea a lot. Say your wrapper is installed in /usr/local/share/euphoria/include/curl. Then you might expect to find your DLL in /usr/local/share/euphoria/include/curl/curl.dll. What I like most about this solution is that you can dynamically figure out where the DLL should be based on the return value from include_paths function. What I don't like about this solution is that a DLL is not an include file.

3. Re: If you wanted to distribute a dll

• Posted by xecronix Sep 12, 2015
• 1705 views

This seems like a reasonable place to start:

namespace libhelper 
include std/filesys.e 
 
public function include_derived_ext_paths(sequence libdir, sequence lib) 
    sequence inc_paths = include_paths(1) 
    sequence retval = {} 
    retval = append(retval, sprintf("%s.%s", {lib, SHARED_LIB_EXT})) 
    sequence current = join_path({current_dir(), sprintf("%s.%s", {lib, SHARED_LIB_EXT})}) 
    retval = append(retval, current) 
    for i = 1 to length(inc_paths) do 
        sequence inc_path = inc_paths[i] 
        sequence last_char = {inc_path[$]} 
        if equal(last_char, SLASH) then 
            inc_path = inc_path[1..$-1] 
        end if 
        retval = append(retval, join_path({inc_path, libdir, "ext", sprintf("%s.%s", {lib, SHARED_LIB_EXT})})) 
    end for 
    return retval 
end function 

So passing

include_derived_ext_paths(coollib, coollib)  

yeilds

{ 
  "coollib.so", 
  "/home/ronald/my/current/working/dir/coollib.so", 
  "/home/ronald/my/current/working/dir/coollib/ext/coollib.so", 
  "/usr/local/share/euphoria/include/coollib/ext/coollib.so" 
} 

5. Re: If you wanted to distribute a dll

• Posted by xecronix Sep 14, 2015
• 1606 views

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.

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.

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.

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.

7. Re: If you wanted to distribute a dll

• Posted by xecronix Sep 14, 2015
• 1612 views

public function include_derived_ext_paths(sequence libdir, sequence lib) 
-- *snip* -- 

 
ifdef WINDOWS then 
    if current[1] = '\\' then 
        -- trim leading backslash character 
        current = current[2..$] 
    end if 
end ifdef 
 

Good idea. I pushed the change.