add bin (if it exists) directory to PATH on win32 #32
Conversation
in order to use the .dll on MSWin32 and cygwin, it must be in the PATH
|
I don't believe this is necessary as I am directly loading the files using DynaLoader. My test cases (see Acme::Alien::DontPanic and Acme::FordPrefect) pass on windows. |
|
I believe I needed this for Alien::Libarchive, I will take a look and see if it is specific to that case. |
|
I wasn't able to get Acme::Alien::DontPanic to install on either Strawberry Perl (MSWin32) or Cygwin, but it did build on cygwin. I didn't see any .dll files, just this static lib: I wouldn't expect that to exercise the behavior that I am seeing. Or maybe that is a dll export library and the .dll was missing? I am not sure. This is the error in Cygwin that I am seeing: cygcheck reveals that it can't find cygarchive-13.dll on MSWin32 (Strawberry) I get a GUI error "The program can't start because libarchive.dll is missing from your computer. Try reinstalling the program to fix this problem". I am doing some funny contortions on MSWin32 because it uses CBuilder instead of autoconf, but the cygwin version is mostly vanilla. btw- this is what I get trying to install Acme::Alien::DontPanic: How are you building on Windows? I wouldn't expect that to work without something like MSYS, and even then, I would expect "configure" to be written "sh configure" there. If this is supposed to work some documentation on how to get it to work on windows would be helpful. This is the test failure on cygwin: |
|
@plicease, with the benefit of a little separation in time, may I ask you to review your own code, and then merge if you feel it's ready? |
|
I am not 100% on board with this solution at the moment. It's not a terrible solution, but if there are binaries installed in that bin directory in addition to the .dll files then it changes the behavior of the environment in subtle ways. The way I ended up solving this in Alien::Libarchive was actually to use static libraries (#11). The problem is that at the moment the only solution that I see for #11 requires some intervention on the part of an author using Alien::Base. |
|
If it requires a hook from an A::B subclasser, we could add an interface for that? What kind of hooks might be required? |
|
I am not sure I follow what you mean. |
The "intervention" I'm assuming could in a perfect world be dealt with by passing a code-ref in some fashion? |
|
sadly, no code-refs are allowed. This is a limitation on the way all Perl build systems serialize their state to support the multiphase build process (configure, build, test, install, etc). I wish it weren't so, but there it is. |
|
So one could pass text that could be evaluated to be a code-ref? I don't know MB at all well, but I think I saw that in a Build.PL today. |
|
Subclassing may also be an option. |
|
The lack of state inherent in this build style of Perl modules was actually motivating me to make my own attempt at a Module::Build reimplementation. It had a central module that would get loaded each time (which could register callbacks/hooks by name), state could still be serialized, but it wouldn't be the only way that the system operates in later phases. In this way, when an event was emitted, it could call user-specified callbacks. Short of this, I don't think it can be done. |
|
I don't see how forcing static libraries could possibly work on If upgraded libraries are a problem then the Alien::XXX implementor However, if the libraries are only distributed as DLLs, then the This seems a reasonable approach only for platforms where Recommend the ticket is still relevant. On Thu, Sep 4, 2014 at 8:10 AM, Graham Ollis notifications@github.com
|
|
DLLs in the share directory should be discouraged since an upgrade to |
|
I think part of the disconnect here is that most of the libraries that I care about can be built pretty easily from source, even on windows with the new |
|
Pretty much any standard MS library, other vendors libraries, On Thu, Sep 4, 2014 at 6:38 PM, Graham Ollis notifications@github.com
|
|
Okay, but some specific examples would help so that we can start addressing them. Again, 99% of the stuff I care about is handled by building from source. |
|
btw- I am not trying to be flippant or rude or anything, I am just saying that we work in different worlds. Linux and open source is where I do most of my coding and Windows is a sort of interesting sideline. If you gave me one or two specific libraries, preferably something that would be useful for PDL or something that would have an actual customer, then we could start working on specific issues and work toward some general solutions. |
|
I expect that darn near everything on this page is distributed as compiled libraries (of wildly varying quality I might add). |
|
That page requires login to download the few things that I tried. That isn't going to easily work with |
|
It seems to me that we should treat dynamic-only libraries on Windows as a special case. (It seems that's what many build systems are—lots and lots of special cases.) I think that @plicease's original suggestion can still be used:
The first part is already done with For users of use Alien::Foo dll_path => 0;and in $_{dll_path} ||= 1;
if( $win32 && $dll_only && -d "$dist_dir/dynamic" && $_{dll_path} ) {
add_to_path();
} |
|
That addresses the problem where extraneous .exe files are in the bin directory, but not the problem that upgrades to One solution would be to install to However, I earnestly believe that we need a concrete and specific example of a library that only comes with DLLs and no source that could be downloaded automatically and installed in an |
|
Sounds like we should make a new Acme module? |
|
I found one example that comes with source, but does not build static libraries. I just got when I run P.S. |
|
@zmughal, I intended to respond a while ago. Here is the commit where they disabled static builds: It isn't critical right this moment, since as you say |
|
I do need it for Right, I agree on having push back on the developers and I did see the following on the ZeroMQ MSWin32 installer page: so this may be resolved soon. Also, for the cases where one does try to add the DLL to the path, it might be a good idea to have a warning that suggests the |
|
I don't mind the idea of modifying the Also, sidenote that I would like to see more generic usage of platform conforming code rather than the hardcoded per-platform path and PATH separators. See |
|
@jberger agree with everything you said here. Just to clarify I was suggesting only modifying the PATH for the Perl process, not system wide. |
in order to use .dlls on MSWin32 and cygwin, they must be in the PATH. This patch adds the bin directory, where the dlls are normally placed, if it exists.
The only downside to this I can see is that there may be some unwanted .exe files in the bin directory as well, at the cost of some complexity, it may pay do one of: