I’ve got pike 8.0 building (for the most part) on windows. A few problems that still exist:
1. not all of the modules are working properly, though i suspect that’s primarily due to my build environments libs being out of whack.
2. Hilfe doesn’t seem to work properly: it starts and then immediately exits.
3. there is a problem on modules that execute pike scripts using $(RUNPIKE)… these scripts run on the host computer, and since RUNPIKE by default points to the newly built binary, the build …
[View More]isn’t able to continue because the host isn’t windows. It seems like it should be using the pike script in the build directory, which would probably be $(FINAL_PIKE), but I don’t want to make that change to configure.in without some feedback.
For now, I’m going to move on to other things until some more feedback arrives.
Bill
[View Less]
I’ve committed a new feature to 8.1 that I’d like to get feedback on. The feature extends master()->add_module_path() to allow the path to point to a ZIP archive which will be searched as if it were a regular module directory.
Things I’d especially like feedback on:
1. Is the current API acceptable (the simplest form is built into add_module_path(), more complex use cases may be accounted for using lower level APIs)
2. A minor overhead exists (a mapping lookup on the path prefix) which may …
[View More]impact performance for non-archive path searches. Since classes are cached after lookup, is this overhead a concern? Quick benchmarking doesn’t seem to indicate a significant performance change, however I’d like to hear thoughts from users whose use case may vary from my own.
3. Does it make sense to extend this feature to add_*_path? My sense is yes, but wanted to check.
Sample Usage:
1. Create a zip file with the following structure:
modules/
modules/Some.pmod/
… etc
2. Run pike -M path/to/some.zip
3. Access Some.whatever…
Bill
[View Less]
