Re: [poc][wip] sqlite3-tcl 3.30.1 + enable tests
> -- Original Message -- > From: Landry Breuil > Date: November 14, 2019 at 3:21 AM > > Does this mean you're going to update/maintain this port again ? :) > > Landry Yes. Stu
Re: [poc][wip] sqlite3-tcl 3.30.1 + enable tests
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 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
Re: [poc][wip] sqlite3-tcl 3.30.1 + enable tests
"some of the SQLITE_ENABLE_XX choices look rather arbitrary." Actually I spent some time carefully poring through all the options so I could provide the best sqlite possible for Tcl. Yeah, so separate please. Stu -- Original Message -- From: Landry Breuil 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
Re: [poc][wip] sqlite3-tcl 3.30.1 + enable tests
Also I don't think this needs to be forced to build against 8.6. Sorry for all the messages, I'm just coming back after almost 2 years away ... whatever that means. Stu -- Original Message -- From: Landry Breuil 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
