Skip to content
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

Separate build dir broken #48401

Closed
nascheme opened this issue Oct 20, 2008 · 15 comments
Closed

Separate build dir broken #48401

nascheme opened this issue Oct 20, 2008 · 15 comments
Assignees
Labels
build The build process and cross-build

Comments

@nascheme
Copy link
Member

BPO 4151
Nosy @mwhudson, @nascheme, @doko42, @tarekziade, @merwok, @agbuckley
Files
  • get_python_inc2.patch: 3.0+ patch
  • get_python_inc2.patch: 2.6+ patch
  • non_posix_srcdir.patch
  • 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/mwhudson'
    closed_at = <Date 2010-08-27.22:01:28.331>
    created_at = <Date 2008-10-20.17:04:15.353>
    labels = ['build']
    title = 'Separate build dir broken'
    updated_at = <Date 2010-09-20.22:02:11.956>
    user = 'https://github.com/nascheme'

    bugs.python.org fields:

    activity = <Date 2010-09-20.22:02:11.956>
    actor = 'eric.araujo'
    assignee = 'mwh'
    closed = True
    closed_date = <Date 2010-08-27.22:01:28.331>
    closer = 'eric.araujo'
    components = ['Build']
    creation = <Date 2008-10-20.17:04:15.353>
    creator = 'nas'
    dependencies = []
    files = ['11838', '11839', '11858']
    hgrepos = []
    issue_num = 4151
    keywords = ['patch']
    message_count = 15.0
    messages = ['74996', '75013', '75085', '81231', '81232', '81234', '81242', '81763', '81796', '82247', '82265', '99402', '108876', '115135', '116987']
    nosy_count = 7.0
    nosy_names = ['mwh', 'nascheme', 'doko', 'tarek', 'eric.araujo', 'rpetrov', 'andybuckley']
    pr_nums = []
    priority = 'normal'
    resolution = 'fixed'
    stage = 'resolved'
    status = 'closed'
    superseder = None
    type = 'compile error'
    url = 'https://bugs.python.org/issue4151'
    versions = ['Python 2.6', 'Python 2.7', 'Python 3.2']

    @nascheme
    Copy link
    Member Author

    Building in a separate directory got broken at some point. The code is
    hairy but it looks like the source of the problem was a lame
    sysconfig.get_python_inc() function. The attached patches fix things
    and hopefully do not introduce any new bugs.

    @nascheme nascheme added build The build process and cross-build labels Oct 20, 2008
    @rpetrov
    Copy link
    Mannequin

    rpetrov mannequin commented Oct 20, 2008

    get_python_inc() and test case is addressed in bpo-4070 as well.

    @nascheme
    Copy link
    Member Author

    [Roumen Petrov]

    Modification for test_build_ext.py from above mentioned issue break
    non-posix builds.

    Without that change the test fails on Unix platforms when the build is
    not done inside the source directory. I guess the problem must be the
    change from (essentially):

    def _get_source_filename():
        return os.path.join(sysconfig.project_base, 'Modules', 'xxmodule.c')

    to

    def _get_source_filename():
        srcdir = sysconfig.get_config_var('srcdir')
        return os.path.join(srcdir, 'Modules', 'xxmodule.c')

    On POSIX, project_base is just the directory containing the Python
    executable. I think the right thing to do is to fix the srcdir var on
    non-POSIX systems. I don't have a Windows machine to test on. Could
    someone test the get_python_inc2.patch with the non_posix_srcdir.patch
    applied on top of it?

    @nascheme
    Copy link
    Member Author

    nascheme commented Feb 5, 2009

    I committed my proposed changes in several chunks, ending with r69305.
    I think building in a separate directory again works and that non-POSIX
    platforms are not adversely affected by this change.

    @nascheme nascheme closed this as completed Feb 5, 2009
    @rpetrov
    Copy link
    Mannequin

    rpetrov mannequin commented Feb 5, 2009

    May be not related to the commit but after clean make fail to build a
    number of modules, as example _bisect. Second run of make build all left.

    The value of srcdir (from Makefile) is ".." without quotes.

    About cleanup: one use of '(srcdir,)==...' left in setup.py .

    @rpetrov
    Copy link
    Mannequin

    rpetrov mannequin commented Feb 5, 2009

    The "clean build' mean missing subdirectory build in <builddir> . Now
    module objects go in build/Modules/. I guess that second make succeed as
    libffi create build directory.

    @nascheme
    Copy link
    Member Author

    nascheme commented Feb 6, 2009

    Roumen, thanks for reporting the bug. It seems that distutils requires
    an absolute path (although I didn't waste time digging too deep into the
    issue).

    @doko42
    Copy link
    Member

    doko42 commented Feb 12, 2009

    still seen on the 2.6 branch. applying r69374 on the branch doesn't fix
    it there.

    @doko42 doko42 reopened this Feb 12, 2009
    @nascheme
    Copy link
    Member Author

    On Thu, Feb 12, 2009 at 01:32:37PM +0000, Matthias Klose wrote:

    still seen on the 2.6 branch. applying r69374 on the branch doesn't fix
    it there.

    The fix is spread over a number of commits: r69374, r69322, r69315,
    r69305, r69304, r69303, r69302. It could be backported but changing
    the build system is always fraught with portability traps and that's
    why it ends up turning to crud over time.

    Obviously most core Python developers don't build in a separate
    directory otherwise this feature won't have been broken for so long.

    @agbuckley
    Copy link
    Mannequin

    agbuckley mannequin commented Feb 16, 2009

    I'm having trouble with this as well :( It's pretty much a blocker for
    integrating distutils-based extension builds with an autotools library
    build, because the "make distcheck" target explicitly does the build in
    a subtree of the source directory, and write-protects the srcdir during
    the build.

    Effectively the source is referred to in my setup.py as living in
    "../../pyext", which translates into distutils attempting to build the
    extension in "build/temp.linux-i686-2.5/../../pyext/", which is the
    write-protected source dir. This would work okay if the directory path
    to the source file were ignored when constructing the output path: would
    the proposed patch(es) fix this?

    @rpetrov
    Copy link
    Mannequin

    rpetrov mannequin commented Feb 16, 2009

    One additional commit change srcdir = os.path.normpath(srcdir) to
    srcdir = os.path.abspath(srcdir) and this should not create relative
    path. In this case I expect build in directory
    build/temp.<PLATFORM_VERSION>/<ABS_SRC_PATH>.

    Andi, did above change work for you.

    @doko42
    Copy link
    Member

    doko42 commented Feb 16, 2010

    current status with 2.7 alpha3:

    FAIL: test_get_python_inc (distutils.tests.test_sysconfig.SysconfigTestCase)
    ----------------------------------------------------------------------

    Traceback (most recent call last):
      File "/home/packages/python/2.7/python2.7-2.7~a3/Lib/distutils/tests/test_sysconfig.py", line 47, in test_get_python_inc
        self.assertTrue(os.path.isfile(python_h), python_h)
    AssertionError: /home/packages/python/2.7/python2.7-2.7~a3/build-static/Include/Python.h

    unsure about this one:
    FAIL: test_finalize_options (distutils.tests.test_build.BuildTestCase)
    ----------------------------------------------------------------------

    Traceback (most recent call last):
      File "/home/packages/python/2.7/python2.7-2.7~a3/Lib/distutils/tests/test_build.py", line 24, in test_finalize_options
        self.assertEquals(cmd.build_purelib, wanted)
    AssertionError: 'build/lib.linux-i686-2.7' != 'build/lib'

    @nascheme
    Copy link
    Member Author

    I believe the latest problem reported has been fixed by SVN rev 80649.

    @nascheme nascheme self-assigned this Jun 28, 2010
    @merwok
    Copy link
    Member

    merwok commented Aug 27, 2010

    I think so too.

    @merwok merwok closed this as completed Aug 27, 2010
    @merwok merwok assigned mwhudson and unassigned nascheme Aug 27, 2010
    @merwok
    Copy link
    Member

    merwok commented Sep 20, 2010

    For the record, I’m not clear about what is fixed or not in each branch.

    @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

    4 participants