-
-
Notifications
You must be signed in to change notification settings - Fork 553
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
Use distutils to compile libcsage #17484
Comments
comment:1
Sounds fine to me, would you unify it with the building of the rest of "sage library" or do you see it still as a separate target? |
comment:2
Unify as much as possible. |
This comment has been minimized.
This comment has been minimized.
Author: Jeroen Demeyer |
Branch: u/jdemeyer/ticket/17484 |
Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:
|
Commit: |
comment:7
lgtm |
Reviewer: Volker Braun |
comment:9
Thanks! |
comment:10
Doctest failures after |
comment:11
I'll prepare a patch factoring out the compiler flags stuff for both |
Branch pushed to git repo; I updated commit sha1. New commits:
|
Branch pushed to git repo; I updated commit sha1. New commits:
|
comment:16
As far as sage-on-gentoo is concerned this is potentially worse than before. I have to unravel the logic that install libcsage before building the extension proper. It all should be able to build with "python setup.py build" and shouldn't rely on "python setup.py install". At least before there was a clear separation between the building of clib and the rest, so we could install one then the other. This so far doesn't allow me to do it in two separate "units". And it doesn't work with a strategy that involve staging your files before installing them, which may be a concern if we go with hashdist and it does staging. |
comment:21
Ok this is how libcsage is being built on OS X, note that distutils doesn't think it is any different from the other extensions and there lie our problem
I also note that two .cpp files are compiled with gcc rather than g++ while the final linking is done by g++. The "-bundle" added for python extensions is our problem, we could try to over-ride it by adding "-dylib" on OS X. |
comment:22
Replying to @kiwifb:
I see. Apparently in OS X shared libraries and loadable modules are different things. See http://docstore.mik.ua/orelly/unix3/mac/ch05_03.htm And distutils doesn't support building shared libraries... |
comment:23
Replying to @kiwifb:
That's a well-known distutils issue, but usually one can get away with it: GCC knows that files with a |
comment:24
Replying to @kiwifb:
I think you are missing the final subdirectory, on my system it is |
comment:26
Replying to @jdemeyer:
Definitely build/lib here. Probably a difference in python configuration or something. Probably best to find it from distutils if possible. But the OS X thing may be a bigger trouble. |
comment:27
While it would be interesting to build libcsage with distutils it looks like it would be quite difficult. So I think we should adopt another strategy. A simple Makefile could do the trick and even be used to execute setup.py. Another serious thought in that regards, libcsage hardly ever change these days and is a requirement to build sage. Could we consider building it as a separate package? It is a small compilation but it feels wholly unnecessary to rebuild it in most case if you perform an upgrade. |
comment:29
Replying to @kiwifb:
I would actually vote for the opposite: And I really don't want another |
comment:30
Replying to @kiwifb:
Sure, that must be doable.
Do you know that it's just a matter of replacing |
comment:31
Another possibility would be to try to compile |
comment:32
I would be ok with it as a cython module. As for replacing -bundle by -shared, since it looks like it is passed to ld I would try -dylib. Of course it has to be OS X specific in that case. |
comment:33
Replying to @kiwifb:
Of course, but I'm not entirely sure if that can actually be done. I'll look into it though. |
comment:34
Replying to @jdemeyer:
Thinking about it, that would probably mean touching a considerable number of cython extensions if not all of them. If we still use distutils we'll have to try -shared or may be -Wl,-dylib but not -dylib directly as it is not a listed option https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/Darwin-Options.html#Darwin-Options. |
comment:35
@kiwifb: could you please post the output of
|
comment:36
Assuming that python is enough rather than sage:
OS X (10.10)
|
comment:37
Close as wontfix? |
comment:38
OK but we'll need to find something. I was so looking forwards to eliminate the current situation. |
As a much simpler alternative to the current SCons approach or the proposed autotools approach at #15594, let's just use distutils to unify the building of
libcsage.so
and the Cython modules.The main advantages are to have one less reason for SCons and to simplify the build process.
This also fixes the bug that simply running
make
doesn't work after modifyingc_lib
headers, one really needs to do first./sage -b
and thenmake
.CC: @vbraun @ohanar
Component: build
Author: Jeroen Demeyer
Branch/Commit: u/jdemeyer/ticket/17484 @
c7ef009
Reviewer: Volker Braun
Issue created by migration from https://trac.sagemath.org/ticket/17484
The text was updated successfully, but these errors were encountered: