add SConstruct

[dholth]

I replied on distutils-sig about potentially building your Python package with SCons + enscons... the first step would be to build the C portion correctly. How's this?

pip install scons then run scons

[dholth]

I don't know how to say whether this is working. Let me know if you get a chance to pip install enscons and then run scons in the python/ folder. I've also set build-backend = "enscons.api" in pyproject.toml which will cause pip to try to build the package with enscons but that probably won't work yet.

[catern]

There are no unconventional dependencies, so you should be able to try installing those and building it yourself. The Python tests can be run through Python stdlib unittest discovery.

I have to say I'm not really interested in having two build systems, nor am I interested in replacing autotools with scons. I appreciate your enthusiasm for scons though. :)

A few things I noticed you may have missed: It appears that the scons build files aren't generating the pkgconfig, and I'm guessing they don't install the programs into libexec - those programs should not going into bin, they should go into libexec.

I also noticed you switched cffi to not use pkgconfig. That's undesirable, using pkgconfig is important for when the C library is separately built and installed.

Daniel Holth notifications@github.com writes:

I have no way of knowing if this is working. Let me know if you get a chance to pip install enscons and then run scons in the python/ folder.

-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/catern/rsyscall/pull/1#issuecomment-501899890

[dholth]

Interesting. I suppose you are also not interested in replacing setuptools with SCons and using a SCons builder to run automake when building the library for the python extension? I was hacking on it using a machine that doesn't have automake installed. The buuld uses rpath to find the .so built just for Python, but I see how it might be important to use a real shared systemwide one.

If setup.py built a bundled library, how would it decide whether to use an embedded version or a system version? Does pkgconfig handle both cases?

I'm interested in improving enscons into a reasonable setuptools replacement, so it's interesting to build different packages with the tool to see what could be streamlined.

On Thu, Jun 13, 2019, at 8:20 PM, catern wrote:

There are no unconventional dependencies, so you should be able to try installing those and building it yourself. The Python tests can be run through Python stdlib unittest discovery.

I have to say I'm not really interested in having two build systems, nor am I interested in replacing autotools with scons. I appreciate your enthusiasm for scons though. :)

A few things I noticed you may have missed: It appears that the scons build files aren't generating the pkgconfig, and I'm guessing they don't install the programs into libexec - those programs should not going into bin, they should go into libexec.

I also noticed you switched cffi to not use pkgconfig. That's undesirable, using pkgconfig is important for when the C library is separately built and installed.

Daniel Holth notifications@github.com writes:

I have no way of knowing if this is working. Let me know if you get a chance to pip install enscons and then run scons in the python/ folder.

-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/catern/rsyscall/pull/1#issuecomment-501899890

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/catern/rsyscall/pull/1?email_source=notifications&email_token=AABSZERFO5ZXNEDDFMICCQDP2LP5PA5CNFSM4HXU7QF2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXVMAFY#issuecomment-501923863, or mute the thread https://github.com/notifications/unsubscribe-auth/AABSZEWWYOQGCB4SZVCEZKLP2LP5PANCNFSM4HXU7QFQ.

[catern]

On Jun 13, 2019 8:44 PM, Daniel Holth notifications@github.com wrote:

Interesting. I suppose you are also not interested in replacing setuptools with SCons and using a SCons builder to run automake when building the library for the python extension?

Possibly, but I don't see what the advantage would be - does SCons have something built in to do this out of the box?

I was hacking on it using a machine that doesn't have automake installed. The buuld uses rpath to find the .so built just for Python, but I see how it might be important to use a real shared systemwide one.

If setup.py built a bundled library, how would it decide whether to use an embedded version or a system version? Does pkgconfig handle both cases?

I think I would be able to just set PKG_CONFIG_PATH at build time to point to the embedded version, but I'm not sure how best to install/store the built library when built by setuptools.

I'm interested in improving enscons into a reasonable setuptools replacement, so it's interesting to build different packages with the tool to see what could be streamlined.

On Thu, Jun 13, 2019, at 8:20 PM, catern wrote:

There are no unconventional dependencies, so you should be able to try

installing those and building it yourself. The Python tests can be run

through Python stdlib unittest discovery.

I have to say I'm not really interested in having two build systems, nor

am I interested in replacing autotools with scons. I appreciate your

enthusiasm for scons though. :)

A few things I noticed you may have missed: It appears that the scons

build files aren't generating the pkgconfig, and I'm guessing they don't

install the programs into libexec - those programs should not going into

bin, they should go into libexec.

I also noticed you switched cffi to not use pkgconfig. That's

undesirable, using pkgconfig is important for when the C library is

separately built and installed.

Daniel Holth notifications@github.com writes:

I have no way of knowing if this is working. Let me know if you get a chance to pip install enscons and then run scons in the python/ folder.

--

You are receiving this because you are subscribed to this thread.

Reply to this email directly or view it on GitHub:

https://github.com/catern/rsyscall/pull/1#issuecomment-501899890

—

You are receiving this because you authored the thread.

Reply to this email directly, view it on GitHub https://github.com/catern/rsyscall/pull/1?email_source=notifications&email_token=AABSZERFO5ZXNEDDFMICCQDP2LP5PA5CNFSM4HXU7QF2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXVMAFY#issuecomment-501923863, or mute the thread https://github.com/notifications/unsubscribe-auth/AABSZEWWYOQGCB4SZVCEZKLP2LP5PANCNFSM4HXU7QFQ.

—You are receiving this because you commented.Reply to this email directly, view it on GitHub, or mute the thread.

[dholth]

enscons adds Python packaging related commands to SCons, and it adds a PEP 518 pluggable build system interface so that enscons can be on equal footing with old setup.py-based distributions. Flit and poetry are other newer build systems to compete with setuptools. You might want to use any build system in place of setuptools or the standard library's distutils because they are likely to be easier to extend, and may be faster because of the "rebuild only if source has changed" feature. Any build system would do a better job of chaining tasks e.g. generate source > compile generated source > package than setuptools. Maybe automake needs a wheel builder 😉