search

utelle / apsw-sqlite3mc

Another Python SQLite wrapper bundled with SQLite3 Multiple Ciphers
https://utelle.github.io/SQLite3MultipleCiphers
Other
0 stars 0 forks source link

Enable headers and APIs on UNIX platforms #7

Closed rogerbinns closed 4 weeks ago

rogerbinns commented 4 weeks ago

SQLite uses configure to work out if various APIs and header files are available. If not run then SQLite falls back to older APIs, omits calls, or emulates them. Examples are re-entrant time functions, fdatasync, usleep.

configure and its associated files are not included in the sqlite3mc amalgamation distribution.

utelle commented 4 weeks ago

SQLite uses configure to work out if various APIs and header files are available. If not run then SQLite falls back to older APIs, omits calls, or emulates them. Examples are re-entrant time functions, fdatasync, usleep.

configure and its associated files are not included in the sqlite3mc amalgamation distribution.

SQLite's amalgamation distribution doesn't contain configure etc either. That's why I chose the same approach.

However, the SQLite3 Multiple Ciphers project itself includes configure support.

rogerbinns commented 4 weeks ago

SQLite's amalgamation does indeed contain configure! Check https://sqlite.org/download.html

The zip file doesn't contain configure, but the .tar.gz does. It makes sense as Windows would prefer .zip and doesn't need configure while Unix would prefer .tar.gz and doesn't need configure, but works better with it. When apsw setup.py downloads SQLite, it always downloads the.tar.gz.

It is a stupid amount of work and files just to get the DEFS = .... out of the generated Makefile in order to add them to the compilation. In the commits for this I deliberately put the configure stuff in a separate subdirectory.

utelle commented 4 weeks ago

SQLite's amalgamation does indeed contain configure! Check https://sqlite.org/download.html

You are right. There are 2 amalgamation archives, one ZIP file for Windows, one tar.gz file for Unix-like platforms. Since I myself work most of the time under Windows and the vast majority of inquiries I receive are Windows-related, I've lost sight of the Unix world a little. 😉

The zip file doesn't contain configure, but the .tar.gz does. It makes sense as Windows would prefer .zip and doesn't need configure while Unix would prefer .tar.gz and doesn't need configure, but works better with it.

Probably I should consider to provide a similar tar.gz archive for the SQLite3 Multiple Ciphers releases.

It is a stupid amount of work and files just to get the DEFS = .... out of the generated Makefile in order to add them to the compilation. In the commits for this I deliberately put the configure stuff in a separate subdirectory.

Thanks for all your work on this project.

rogerbinns commented 4 weeks ago

You should be able to do all the Linux stuff using WSL. Heck using vscode it has a plugin, so you never need to touch Linux!

As far as I can tell the majority of software development done by multiple collaborating developers is all going Linux container based to define the dev environment, CI, building, deployment, versioning etc.

The downloads from pypi are all linux based, I'm guessing because of the containers. Less than 1% is Windows or Mac - details at https://pypistats.org/packages/apsw

To support that world you have to figure out what 1 line does someone have to add to a Dockerfile to deploy the project..

rogerbinns commented 4 weeks ago

I've committed a short tool and updated the release procedure page to keep the configure stuff in sync with SQLite amalgamation.

utelle commented 4 weeks ago

You should be able to do all the Linux stuff using WSL. Heck using vscode it has a plugin, so you never need to touch Linux!

Don't get me wrong. I'm not afraid of using Linux. Actually, I have several virtual machines running Linux. Many years ago - long before WSL existed - I started to use VMware for running different OSes.

As far as I can tell the majority of software development done by multiple collaborating developers is all going Linux container based to define the dev environment, CI, building, deployment, versioning etc.

At the company and the customer I was working for Windows was the main development platform. Yes, development is shifting to container-based environments and cloud-based environments, but it is slow transition.

The downloads from pypi are all linux based, I'm guessing because of the containers. Less than 1% is Windows or Mac - details at https://pypistats.org/packages/apsw

To support that world you have to figure out what 1 line does someone have to add to a Dockerfile to deploy the project.

I do my best to adjust myself to a changing world. 😉