[PyQt] [SIP] Multi-platform pyproject.toml (platform dependent values)

[Matteo Bertini]

This quick and dirty patch does what I suggested:

    diff -r d82ebe4b05b2 sipbuild/bindings.py
    --- a/sipbuild/bindings.py      Fri Oct 04 23:29:15 2019 +0100
    +++ b/sipbuild/bindings.py      Thu Dec 12 14:33:07 2019 +0100
    @@ -245,7 +245,25 @@
                         copy_nonshared_sources(project.abi_version,
                                 buildable.build_dir))

    -        buildable.include_dirs.extend(self.include_dirs)
    +        from packaging.markers import Marker
    +
    +        def filter_markers(values):
    +            return [item for item in (filter_marker(v) for v in
values) if item is not None]
    +
    +        def filter_marker(value):
    +            if ";" not in value:
    +                return value
    +            value, marker = value.split(";", 1)
    +            if Marker(marker).evaluate():
    +                return value
    +
    +        def abspath_from_root_dir(path):
    +            if os.path.isabs(path):
    +                return path
    +            else:
    +                return os.path.join(project.root_dir, path)
    +
    +        buildable.include_dirs.extend([abspath_from_root_dir(path) for
path in filter_markers(self.include_dirs)])
             buildable.sources.extend(self.sources)

             if self.protected_is_public:
    @@ -254,8 +272,8 @@

             buildable.define_macros.extend(self.define_macros)

    -        buildable.libraries.extend(self.libraries)
    -        buildable.library_dirs.extend(self.library_dirs)
    +        buildable.libraries.extend(filter_markers(self.libraries))
    +        buildable.library_dirs.extend([abspath_from_root_dir(path) for
path in filter_markers(self.library_dirs)])

             return buildable

This allows to use this syntax in `pyproject.toml`:

    [tool.sip.bindings.somemodule]
    include-dirs = [".",
                    "linux; 'linux' in sys_platform",
                    "win32; 'win32' in sys_platform"]
    library-dirs = ["linux; 'linux' in sys_platform",
                    "win32; 'win32' in sys_platform"]
    libraries = ["somelib64; 'linux' in sys_platform and 'x86_64' in
platform_machine",
                 "somelib32; 'linux' in sys_platform and 'x86_64' not in
platform_machine",
                 "usb-1.0;   'linux' in sys_platform",
                 "user32;    'win32' in sys_platform"]

Notable changes:

1) non-absolute paths are considered relative to `project.root_dir` aka the
`pyptoject.toml` folder if I'm correct,
2) a bunch of fields are filtered if containing `;` and
`packaging.markers.Marker` is used to do the real work.

I'm quite confident that 1) is an expected behaviour, perhaps with some
check or better error / warning message if the joined path is invalid.

Instead 2) can result in unwanted errors, because the presence of the `;`
is used to activate a parsing that may fail with some existing user input.

Can we provide a list variable to let the user opt-in the marker
evaluation? Something like:

    [tool.sip.bindings.somemodule]
    evaluate-markers = ["include-dirs", "library-dirs", "libraries"]

We can perhaps find a default set of fields that one can enable with a
single boolean option, just to avoid the listing, something like:

    [tool.sip.metadata]
    name = "somemodule"
    evaluate-default-markers = true

Should I move this config into a custom `project.py` or integrate it better
into the mainline one (open to suggestions)?

Cheers,
Matteo

On Thu, Dec 12, 2019 at 11:18 AM Phil Thompson <phil at riverbankcomputing.com>
wrote:

> On 12/12/2019 09:15, Matteo Bertini wrote:
> > On Wed, Dec 11, 2019 at 11:04 PM Phil Thompson
> > <phil at riverbankcomputing.com>
> > wrote:
> >
> >> On 11/12/2019 15:46, Matteo Bertini wrote:
> >> >
> >> > I tried using this syntax
> >> > https://www.python.org/dev/peps/pep-0566/#environment-markers:
> >> >
> >> >     libraries = ["usb-1.0; 'linux' in sys_platform"]
> >> >
> >> > But seems to be unsupported.
> >>
> >> If you need to do any introspection (ie. you need to write code) then
> >> you need a project.py file.
> >>
> >
> > Can you point me to some documentation or example? Searching the
> > filename
> > gives me a lot of unrelated results.
>
>
> https://www.riverbankcomputing.com/static/Docs/sip/examples.html#package-projects
>
> >
> > Alternatively, is there some interest in supporting the linked
> > environment-markers syntax? (or even, if I spend some time on the
> > feature,
> > are you interested in merging it?)
>
> I'd consider it. My concern would be that the vast majority of cases
> would need a project.py file anyway.
>
> >> > 2) I tried using paths relative to `pyproject.toml` bus sip fails not
> >> > finding my `.h` files (found using the absolute path), what is the
> best
> >> > practice here?
> >>
> >> Configure 'include_dirs'?
> >>
> >
> > Let me explain, my project is in `/home/matteo/someproject`, with
> > `pyproject.toml` and `somename.sip` + `somename.h` in the root of the
> > project.
> >
> >   [tool.sip.bindings.somename]
> >   include-dirs = ["."]
> >
> > ^^^ fails, instead the absolute path below works:
> >
> >    [tool.sip.bindings.somename]
> >    include-dirs = ["/home/matteo/someproject"]
>
> Using ".." might be better as the current directory should be the build
> directory which (by default) is a sub-directory of the root directory
> (the one containing pyproject.toml). However that would break in the
> case with a different build directory.
>
> The normal thing would be to set include_dirs in project.py based on the
> value of the "root_dir" attribute. As I've said, at the moment at least,
> a project.py file is needed in all but the most trivial of cases but I'm
> open to suggestions as to how that can be improved. For example allowing
> you to say something like...
>
>      include-dirs = ["$ROOT_DIR"]
>
> Phil
>


-- 
/ Matteo Bertini
\ naufraghi at develer.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.riverbankcomputing.com/pipermail/pyqt/attachments/20191212/35e873cc/attachment.html>