Skip to content

_ctypes and other modules not built with msbuild on vs2010 solution #59026

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

Closed
jaraco opened this issue May 16, 2012 · 9 comments
Closed

_ctypes and other modules not built with msbuild on vs2010 solution #59026

jaraco opened this issue May 16, 2012 · 9 comments
Assignees
Labels
build The build process and cross-build

Comments

@jaraco
Copy link
Member

jaraco commented May 16, 2012

BPO 14821
Nosy @jaraco, @pitrou, @kristjanvalur, @briancurtin

Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

Show more details

GitHub fields:

assignee = 'https://github.com/briancurtin'
closed_at = <Date 2012-05-24.12:28:21.758>
created_at = <Date 2012-05-16.00:10:11.565>
labels = ['build']
title = '_ctypes and other modules not built with msbuild on vs2010 solution'
updated_at = <Date 2012-05-24.12:28:21.757>
user = 'https://github.com/jaraco'

bugs.python.org fields:

activity = <Date 2012-05-24.12:28:21.757>
actor = 'jaraco'
assignee = 'brian.curtin'
closed = True
closed_date = <Date 2012-05-24.12:28:21.758>
closer = 'jaraco'
components = ['Build']
creation = <Date 2012-05-16.00:10:11.565>
creator = 'jaraco'
dependencies = []
files = []
hgrepos = []
issue_num = 14821
keywords = []
message_count = 9.0
messages = ['160780', '160787', '160795', '160798', '161202', '161203', '161204', '161205', '161501']
nosy_count = 5.0
nosy_names = ['jaraco', 'pitrou', 'kristjan.jonsson', 'brian.curtin', 'python-dev']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue14821'
versions = ['Python 3.3']

@jaraco
Copy link
Member Author

jaraco commented May 16, 2012

It appears with the latest changes (cdcc816dea85), ctypes builds as _ctypes_test.pyd, not _ctypes.pyd. This causes 'import ctypes' to fail with an ImportError and thus causes tests to fail that depend on test.support (which imports ctypes).

I first noticed this issue in features/pep-420, but the same behavior is present in the main repository. I cannot test it because Python fails to start altogether, but I see _ctypes_test.pyd in the pcbuild/amd64 directory.

@jaraco jaraco added the build The build process and cross-build label May 16, 2012
@jaraco
Copy link
Member Author

jaraco commented May 16, 2012

I see now that _ctypes is in fact in the solution, and if I open the solution in visual studio and build it manually, it gets built. Even if I just build the solution in visual studio, it gets built.

However, if I run the following command, _ctypes doesn't get built:

msbuild pcbuild.sln /p:Configuration=Release /p:Platform=x64

The output log doesn't mention "ctypes.", so it appears as if it's not attempting to build it at all.

This would work for me a week or two ago, prior to the VS2010 conversion (though I would convert the project before building), so this behavior feels a bit like a regression.

@jaraco
Copy link
Member Author

jaraco commented May 16, 2012

I've discovered a few things:

  • _ctypes depends on pythoncore.
  • other projects that depend on pythoncore are not built by msbuild.
  • If I remove the dependency of _ctypes on pythoncore and then do the build with msbuild, _ctypes is built and I can import ctypes.
  • If instead I explicitly specify _ctypes as a target, it gets built (and along with a regular build, I can import ctypes).

I see why that ctypes does depend on pythoncore, because it needs python33.lib to link.

In trying to discover how to have msbuild attempt to build the entire solution, I ran across this article which says that best practice is not to declare project dependencies in a solution file at all but instead declare project dependencies in the project files themselves (so _ctypes should <Include> pythoncore, for example).

I plan to look into this issue more later.

@briancurtin
Copy link
Member

@loewis loewis mannequin changed the title Ctypes extension module builds as _ctypes_test.pyd _ctypes_test fails to build from the command line with VS 2010 May 19, 2012
@jaraco jaraco changed the title _ctypes_test fails to build from the command line with VS 2010 _ctypes and other modules not built with msbuild on vs2010 solution May 20, 2012
@kristjanvalur
Copy link
Mannequin

kristjanvalur mannequin commented May 20, 2012

I'm able to reproduce this problem with the latest changes to PCBuild.
Are you saying that there are other projects like _ctypes that are not built?

I'm not able to see any different between _ctypes_test and _ctypes on the .vcxsproj level that would explain this, or in the sln.

Perhaps there is another bug in msbuild?

@kristjanvalur
Copy link
Mannequin

kristjanvalur mannequin commented May 20, 2012

Hm, I see that this applies to _decimal, _testbuffer and xxlimited too. When msbuild is invoked with MSBUILDEMITSOLUTION=1, it leaves a .metaproj file in place for those projects.

@kristjanvalur
Copy link
Mannequin

kristjanvalur mannequin commented May 20, 2012

Found the issue. Manual dependencies in the .sln file had to be removed.

@python-dev
Copy link
Mannequin

python-dev mannequin commented May 20, 2012

New changeset 2e96629c6dab by Kristján Valur Jónsson in branch 'default':
bpo-14821:
http://hg.python.org/cpython/rev/2e96629c6dab

@jaraco
Copy link
Member Author

jaraco commented May 24, 2012

Excellent! The latest tip now builds nicely using msbuild.

@jaraco jaraco closed this as completed May 24, 2012
@ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
build The build process and cross-build
Projects
None yet
Development

No branches or pull requests

2 participants