preliminary windows support via some new flags #164
Conversation
PYNACL_SODIUM_LIBRARY_NAME lets you set what it should be trying to link against PYNACL_SODIUM_STATIC will define SODIUM_STATIC before include to set the proper dllexport visibility for static linking on windows
| source.append("#include <sodium.h>") | ||
|
|
||
| if os.getenv("PYNACL_SODIUM_LIBRARY_NAME") is not None: | ||
| libraries = [os.getenv("PYNACL_SODIUM_LIBRARY_NAME")] |
There was a problem hiding this comment.
Why would someone need a custom name?
There was a problem hiding this comment.
The Windows library naming scheme makes this somewhat useful. When you ask for "sodium" on linux/OS X it gets translated to "libsodium.so" or "libsodium.dylib" but on windows it just looks for "sodium.lib". The libsodium precompiled libraries, however, call it "libsodium" on windows. We could just rename it to "sodium" but it's nice to be able to use the libsodium.org download without renaming a bunch of files.
Alternately we could just define the library name to be "libsodium" on Windows, but that does mean windows users (at least the ones who want to compile it themselves) need to know that we require the library to be named that.
I'm neutral on which approach we take here (although there is a reasonable argument to be made that it's unlikely anyone on Windows is going to name it anything other than "libsodium")
There was a problem hiding this comment.
Sorry, if the libsodium binaries name it libsodium, why can't we just write "libsodium" here and be happy?
There was a problem hiding this comment.
If you compile it yourself it won't necessarily be named that, but as I said before, if anyone is compiling it themselves it is perhaps reasonable to state that they need to learn what the expected name is for linking.
There was a problem hiding this comment.
Why wouldn't it be named that -- is there a different default for
self-compiled, no default, or just "someone might change it"?
On Sat, Jan 9, 2016 at 10:53 AM, Paul Kehrer notifications@github.com
wrote:
In src/bindings/build.py
#164 (comment):@@ -34,6 +34,17 @@
with open(header, "r") as hfile:
ffi.cdef(hfile.read())+# we need to easily control a few values for Windows builds
+source = []
+if os.getenv("PYNACL_SODIUM_STATIC") is not None:
- source.append("#define SODIUM_STATIC")
+source.append("#include <sodium.h>")
+
+if os.getenv("PYNACL_SODIUM_LIBRARY_NAME") is not None:
- libraries = [os.getenv("PYNACL_SODIUM_LIBRARY_NAME")]
If you compile it yourself it won't necessarily be named that, but as I
said before, if anyone is compiling it themselves it is perhaps reasonable
to state that they need to learn what the expected name is for linking.—
Reply to this email directly or view it on GitHub
https://github.com/pyca/pynacl/pull/164/files#r49265121.
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
GPG Key fingerprint: 125F 5C67 DFE9 4084
There was a problem hiding this comment.
Since there's no suffix difference for static vs dynamic vs link time compile optimization library types Windows people appear to sometimes totally rename their libraries. We saw this with the slproweb OpenSSL library names before we switched to our own for cryptography. In this case there are vcxproj files (at least in the git tree, they don't appear to actually ship in the tarball) for the various VS201X releases that probably do give the "libsodium" name by default.
There was a problem hiding this comment.
Ok, I think just hardcode it to libsodium and we can do something
different if someone complains.
On Sat, Jan 9, 2016 at 10:59 AM, Paul Kehrer notifications@github.com
wrote:
In src/bindings/build.py
#164 (comment):@@ -34,6 +34,17 @@
with open(header, "r") as hfile:
ffi.cdef(hfile.read())+# we need to easily control a few values for Windows builds
+source = []
+if os.getenv("PYNACL_SODIUM_STATIC") is not None:
- source.append("#define SODIUM_STATIC")
+source.append("#include <sodium.h>")
+
+if os.getenv("PYNACL_SODIUM_LIBRARY_NAME") is not None:
- libraries = [os.getenv("PYNACL_SODIUM_LIBRARY_NAME")]
Since there's no suffix difference for static vs dynamic vs link time
compile optimization library types Windows people appear to sometimes
totally rename their libraries. We saw this with the slproweb OpenSSL
library names before we switched to our own for cryptography. In this case
there are vcxproj files (at least in the git tree, they don't appear to
actually ship in the tarball) for the various VS201X releases that probably
do give the "libsodium" name by default.—
Reply to this email directly or view it on GitHub
https://github.com/pyca/pynacl/pull/164/files#r49265169.
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
GPG Key fingerprint: 125F 5C67 DFE9 4084
|
jenkins, retest this please |
| # we need to easily control a few values for Windows builds | ||
| source = [] | ||
| if os.getenv("PYNACL_SODIUM_STATIC") is not None: | ||
| source.append("#define SODIUM_STATIC") |
There was a problem hiding this comment.
Can you add a comment explaining that what this does is cause libsodium to be a static lib... or whatever this define does?
|
|
||
| source.append("#include <sodium.h>") | ||
|
|
||
| if sys.platform == "windows": |
|
jenkins retest this please |
|
jenkins, retest this please |
3 similar comments
|
jenkins, retest this please |
|
jenkins, retest this please |
|
jenkins, retest this please |
preliminary windows support via some new flags
PYNACL_SODIUM_LIBRARY_NAME lets you set what it should be trying to link against.
PYNACL_SODIUM_STATIC will define SODIUM_STATIC before include to set the proper dllexport visibility for static linking on windows.
This PR also should be tested by a new jenkins job... let's see if it works.