Skip to content

Current hard-coded pycairo flags in setup.py hinder installs where Python and pycairo have different prefixes #234

@jwilges

Description

@jwilges

Issue

As in the title, the current hard-coded pycairo flags in setup.py hinder installs where Python and pycairo have different prefixes.

Clarification

In a nutshell, if pycairo resides outside of Python's sys.exec_prefix, the current setup.py behavior is incorrect.

See this Dockerfile gist for an example of this issue in a python:3.8-slim-based container that uses Debian's python3-cairo-dev package to provide pycairo.

Reference

Current setup.py:

if os.environ.get("PYCAIRO", "false") == "true":
    try:
        extra_comp_args.append('-DHAVE_PYCAIRO')
        print("-I%s/include/pycairo".format(sys.exec_prefix))
        extra_comp_args.append("-I{0}/include/pycairo".format(sys.exec_prefix))
        #extra_comp_args.extend(check_output(["pkg-config", '--cflags', 'pycairo']).strip().split(' '))
        #linkflags.extend(check_output(["pkg-config", '--libs', 'pycairo']).strip().split(' '))
    except:
        raise Exception("Failed to find compiler options for pycairo")

It looks like someone tried to leverage pkg-config at some point but ultimately disabled it.

Suggestion

I am attaching a patch that aims to give us the best of both worlds: flags sourced from pkg-config when viable with backward compatible fallback flag values when pkg-config detection fails.

This could be rolled up into a slightly better generic pkg-config pattern if other dependencies could benefit from similar behavior but I made the patch solely for pycairo since that was the only preexisting use case of pkg-config in setup.py.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions