Skip to content

Conversation

@alexfikl
Copy link
Contributor

At least on my system, all these variables seemed to return the same things, so hopefully it doesn't break too much. I also ran the loopy tests and they still pass.

Comment on lines -383 to -387
object_names = [
oname for oname in make_vars["OBJECT_OBJS"].split()
if "(" not in oname and ")" not in oname]

object_suffix = ".{}".format(object_names[0].split(".")[1])
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This just tries to get the extension for objects on the system, right?

It seems sysconfig has a dumber parse_makefile that doesn't parse multiline variables. This switched to check MODOBJS, which seems to be the only variable in the makefile that's defined on a single line :\

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The new code isn't particularly worse than the old code, and it seems to do the job at least on Linux. So, close enough, to me.

cflags.append(lib)

ld, *ldflags = config_vars["LDSHARED"].split()
so_ext = os.path.splitext(config_vars["EXT_SUFFIX"])[-1]
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The previous version seemed to assume that make_vars["SO"] returned an extension, but at least on my system it doesn't exist at all. config_vars["SO"] exists though (from sysconfig), but that returns the cpython-[arch].so.

It also says that "SO" is deprecated in favor of "EXT_SUFFIX".

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, it's .cpython-[arch].so.. was that the intended full suffix here?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that's OK. As long as CPython looks for xyz.cpython-[arch].so for import xyz, that's all that's needed.

@inducer
Copy link
Owner

inducer commented Apr 28, 2022

My biggest worry here is Mac compatibility. Could you add a CI that tries that? (Maybe on main first, to see what passes there?)

@inducer inducer merged commit 0bd0933 into inducer:main Apr 28, 2022
@alexfikl alexfikl deleted the port-distutils branch April 28, 2022 16:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants