gt; Today's Topics:
>
>1. Re: Compiling boost python (Axel Huebl)
>
>
> --
>
> Message: 1
> Date: Thu, 30 Apr 2020 14:21:40 -0700
> From: Axel Huebl
> To: Development of Python/C++ integration
>
;Date: Thursday, April 30, 2020 at 8:30 AM
>To: Development of Python/C++ integration
>Subject: Re: [C++-sig] Compiling boost python
>
>But having one more lib outside boost means one more dependency.
>
>The sad thing is that dropping support for "the oldest and buggiest of
>compil
ation
Date: Thursday, April 30, 2020 at 8:30 AM
To: Development of Python/C++ integration
Subject: Re: [C++-sig] Compiling boost python
But having one more lib outside boost means one more dependency.
The sad thing is that dropping support for "the oldest and buggiest of compiler
specimens
> How the cmake support for pybind ?
I don't know cmake, but I did use pybind11 at my last job. It's
nothing more than header files (no libraries to link). I doubt it
would be difficult to support.
Skip
___
Cplusplus-sig mailing list
Cplusplus-sig@pytho
But having one more lib outside boost means one more dependency.
The sad thing is that dropping support for "the oldest and buggiest of compiler
specimens" in Boost would be rational to do, there are plenty of old Boost
releases for those.
How the cmake support for pybind ?
- On 29 Avr
This blurb might help with that question:
The main issue with Boost.Python—and the reason for creating such a similar
project—is Boost. Boost is an enormously large and complex suite of utility
libraries that works with almost every C++ compiler in existence. This
compatibility has its cost: ar
Have you considered using pybind11? It’s the same basic idea as boost.python,
but it is cleaner, much better supported and documented, and has a large user
community. I just discovered this lately, have been using it, and I’m thrilled
with it. The only catch is that you need to be compiling with
