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
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions