Please keep them separate. Much easier to update either.
If they were tied together and I wanted to update tcl-sqlite I'd have to spend a week testing and convincing. Also, tcl-sqlite isn't built with the same options as the main sqlite port. The tests would be nice but I'm not sure you're going down the right path; the amalgamation build is really the only sensible and mostly-guaranteed-to-work way to build sqlite. Stu ---------- Original Message ---------- From: Landry Breuil <[email protected]> Date: November 9, 2019 at 9:55 AM Hi, sqlite3-tcl is a bit outdated compared to 'main' sqlite3, so im pondering moving back to the previous situation of having them as a single port with multipackages (which was the case before sqlite3 got imported into base) - and while here i hacked my way around to be able to run the tcl test suite. Right now its still running (and seems hung) but that allows to run those natively for each updates. - we need to switch to the -src tarball which is the only one containing tests - that requires horrible hacks to generate configure in the autoconf/tea subdir, + generate tclsqlite3.c wrapper. - that means rerunning configure/building in do-test as the WRKDIST dir changes so its a gross hack, more an interesting exercise in ports wrestling, but finally having sqlite tests. even if it doesnt build with the same options as the main sqlite3 port.. some of the SQLITE_ENABLE_XX choices look rather arbitrary. stu, an opinion about keeping it separate or not ? Landry
