Yeah, it maybe wasn’t engineered this way, but we end up with a shell script hidden in the source tree, depending on m4 you wouldn’t run at runtime. A system subtle enough to run tests against the Pike binary you just compiled instead of the installed one. A marvel for a Pike core hacker :)
Anyway, depending on m4 would disqualify any tool expected to be run on runtime or end-user side. As you suggest, providing testsuite files in the Pike module source code would be the way to go. A pike -x something would make things easier, and a proper CI/CD pipeline could handle the burden. Bertrand > On 8 Sep 2023, at 07:54, H. William Welliver <will...@welliver.org> wrote: > > Well, mktestsuite is just a shell script that runs m4. There isn’t anything > that’s particularly “compile-time centric about it”. And certainly test_pike > could be modified to automatically update the test suite file if needed. > > The m4 dependency means that you wouldn’t necessarily be guaranteed to be > able to generate testsuites on any machine that merely had pike installed > (Windows in particular comes to mind). > > If you’re distributing code as an archive, you could always generate the > testsuite as part of the archive generation process. > > I use test suites to test some of my own code and while I use makefiles to > automate it, there’s no reason it needs to be that way. Making test_pike > regenerate the test suite if necessary would make it even more seamless. > > Even if test_pike weren’t modified to run mktestsuite when necessary, it > might be nice if test_pike noticed that a testsuite.in had been modified and > made a note of it in the output. > > Bill
