Closed lugia19 closed 1 year ago
The only reason I use alloca is because Microsoft stubbornly refuse to support C99 VLA. I think I'll change every platform to use VLA and leave only Windows using alloca to address that issue.
Your $CFLAGS
approach is fine. Other alternatives include -I
option to python3 setup.py build_ext -I/usr/local/include
and having a setup.cfg
file with a [build_ext]
section include-dirs = /usr/local/include
.
I am curious why you don't build apsw the default way that includes the SQLite library into the extension.
Fantastic question, absolutely no clue. What's the 'default way'? I was just doing pip install .
lol.
Ah you aren't getting it from pypi. If you did pip install apsw
then you would get SQLite statically included. It would still build from source, but fetch SQLite source code as a first step.
Since you are building from the source distribution you can get the same effect. Make setup.apsw
have these contents and then do you pip install .
Ah, yes, I had to build it without getting it from pypi directly since I needed to fix the header issue as well. Good info to know, thanks.
I've just released APSW 3.43.1.1 which includes the fix. It will be another hour or two before pypi also includes the updated version.
So, I was trying to update to the latest apsw version, and I had the install fail.
I found two issues:
1) alloca is defined in stdlib.h on freeBSD, rather than alloca.h, so #include fails.
I figured this out thanks to this issue https://github.com/h2o/h2o/issues/47 about a similar problem.
To fix it, I modified the imports in aspw.c like so:
2) The install cannot find sqlite3.h in /usr/local/include/sqlite3.h
To fix this, I simply modified the CFLAGS before building the package, but I'm sure there's a better way to do it in setup.py.
export CFLAGS="-I/usr/local/include $CFLAGS"
3) Bonus, non-package issue included for posterity: You need to be on FreeBSD 13 at least, and switch pkg to latest instead of quarterly, to get sqlite3 3.43.