On Sun, 10 Aug 2008, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:

...

Arne Goedeke wrote:

...

I have a copy of the bugless git repo that compiles but has a missing specs file. I put one there (replacing the path and such) but cannot build cmods using pike -x:

The repo was (and is) a complete snapshot of CVS. So I'd be a bit puzzled if you find missing files.

The specs file is not supposed to be in the repository at all. It is created by the configure script.

Yes, but currently when building from cvs/git its missing. Afair thats an old issue, I saw that before even with an official gentoo package.

Also, could someone say something about those old/new style modules in 7.7. I would like to have my modules on gotpike.org build when 7.8 comes out.

best

arne

Oh, sorry. My mistake. I should have read the README-CVS. The current installation seems to work, however compiling the module does not.

precompile: /home/el/src/Pike/7.7/build/linux-2.6.25-gentoo-r7-i686/test-install/pike/7.7.157/bin/pike /home/el/src/Pike/7.7/build/linux-2.6.25-gentoo-r7-i686/test-install/pike/7.7.157/include/pike/precompile.pike json.cmod /home/el/src/Pike/7.7/build/linux-2.6.25-gentoo-r7-i686/test-install/pike/7.7.157/include/pike/precompile.pike:2:Couldn't read include file "/home/el/src/Pike/7.7/build/linux-2.6.25-gentoo-r7-i686/test-install/pike/7.7.157/include/lib/modules/Tools.pmod/Standalone.pmod/precompile.pike". Pike: Failed to compile script.

It seems like the directories are wrong. Shouldn't it be [...]/7.7.157/lib/modules/[...] without the /include/ ?

I did a 'make tinstall'. Maybe I should do something else instead?

arne

On Sun, 10 Aug 2008, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:

...

Yes, but currently when building from cvs/git its missing.

Umm, nope?

chiyo:~/Pike/7.7/build/linux-2.6.24-20-powerpc-ppc% /home/marcus/Pike/7.7/src/configure [...] config.status: creating post_modules/static_module_makefile config.status: creating modules/dynamic_module_makefile config.status: creating post_modules/dynamic_module_makefile config.status: creating precompile.sh config.status: creating specs <-------------- config.status: creating machine.h config.status: machine.h is unchanged config.status: executing default commands === configuring in modules (/home/marcus/Pike/7.7/build/linux-2.6.24-20-powerpc-ppc/modules) [...] chiyo:~/Pike/7.7/build/linux-2.6.24-20-powerpc-ppc% ls -l specs -rw-rw-r--+ 1 marcus marcus 604 2008-08-10 12:49 specs chiyo:~/Pike/7.7/build/linux-2.6.24-20-powerpc-ppc%

That was with a CVS checkout, and using autoconf 2.61. Do you get different results?

Arne is actually describing a problem that I've been having ever since this "old/new" module thing was created.

1) on the systems I've been using, precompile.sh isn't installed with executable permission. 2) precompile.pike inherits a relative path to the precompile.pike script in Tools.Standalone that is valid in the source tree but not when installed. Thus, an error is generated with any cmod.

Bill

On Aug 10, 2008, at 9:40 AM, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:

tinstall creates a installation for the purpose of running the testsuite (and benchmark). Doing anything else with it isn't really supported.

Either use your uninstalled pike to build the module, or install it with "make install".

The theory is that precompile.sh will use pike -x precompile, not the precompile.pike in the bin-directory. The only reason to keep it in bin is to make it possible to compile pike using a pike that does not have pike -x precompile.

No, there are AFAIK no modules using the new style.

After reading precompile.pike I figured out that my cmod misses a DECLARATIONS statement. Not sure why I did not read about that before.. but apparently pike 7.6 did not need it.

arne

On Sun, 10 Aug 2008, Arne Goedeke wrote:

Not sure if that is a problem. Also compilation breaks because in the .c generated by precompile from the .cmod a define for DEFAULT_CMOD_STORAGE is missing. The compile complains about lines like:

 DEFAULT_CMOD_STORAGE ptrdiff_t f_validate_fun_num = 0;
 DEFAULT_CMOD_STORAGE void f_validate(INT32 args) {

That would have been my next question.

#ifndef .. # define .. #enif

doesnt really do much if placed appropriatly.

arne

On Mon, 11 Aug 2008, Henrik Grubbström (Lysator) @ Pike (-) developers forum wrote:

...

After reading precompile.pike I figured out that my cmod misses a DECLARATIONS statement. Not sure why I did not read about that before.. but apparently pike 7.6 did not need it.

DECLARATIONS is supposed to be automatic, but was apparently broken recently in precompile.pike.

...

arne

On Sun, 10 Aug 2008, Arne Goedeke wrote:

...

Not sure if that is a problem. Also compilation breaks because in the .c generated by precompile from the .cmod a define for DEFAULT_CMOD_STORAGE is missing. The compile complains about lines like:

 DEFAULT_CMOD_STORAGE ptrdiff_t f_validate_fun_num = 0;
 DEFAULT_CMOD_STORAGE void f_validate(INT32 args) {

I didn't see any comments about old/new-style module building, so here is a short explaination.

The old-style, requires modules to have a number of files and pretty much assumes it is a CMOD. If developers want's to distribute a pike-only module, they still have to provide all kinds of stuff to make the build system happy. The old-style compilation also drags in alot of includes created when Pike was compiled, with defines that could be invalid for the machine that is building the module.

So, to work around those problems and simplify module building quite a bit (in most cases), we decided to introduce the new-style module building. This new way of building modules for Pike basically gives the developer the posibility to get CFLAGS, which is really all you need to compile external modules, by running "pike -x cflags".

If you need to test for other features to ensure that your module runs, you should really write your own configure tests and use the results of those to determine if your module can be compiled or not.

There was talk of extracting a bunch of tests from Pike's configure suite to a library which modules can use to test for features. This would be a nice to have feature, since Pike's configure has a ton of workarounds for various situations and strange OS. However, this feature is still to be implemented.

In the end, it should be alot easier to write modules that compiles most of the time. If you want to write a robust module, that checks for prerequisites properly you will probably have to do some more work now, but the end result should be far better and more reliable that it was before.

Currently, yes. But the old style module building framework pretty much assumed you were building a CMOD in general. If you didn't intend to do that, you still had to provide a few files which were more or less empty.

I think that was more of a design-flaw in the old-style method than anything else, but nevertheless...

C-modules should work fine to. I was more thinking of the pure pike modules vs the ones that needs to be compiled in some way. I havn't written a pure C-module in so long, I more or less forgot about those.. :)

I believe you had to include a configure.in script at the very least. I seem to recall there was a need for some other file as well, but that may wrong.

Well, as you say pure Pike modules don't need to be compiled, so they don't need neither the old nor the new style build system.

I think I mentioned this before, but I'll repeat it just so an alternate viewpoint is heard: I guess I fail to see the upside of this "new" way of doing things. Sure, you may get the ability to recheck settings that may have changed since pike's original install, or you want to incorporate an entirely new build system. The (big, in my opinion) downside is that you lose the ability to distribute the module easily, as the "new" method doesn't come with any of the established build and install framework ready to go. It seems to me a far better solution for all modules to use the same mechanism for build/install rather than a split system.

As I think about it I'm not even sure about the benefit gained from being able to recheck things, as if you didn't have something previously, you can always recheck and add it during configure (I've got a number of modules that do that) and if you already had it and changed it, you risk introducing failures due to having different versions of "stuff" used by different parts of the code.

Yes, some have indicated that it's a pain to make a distributable module that only contains a pike file, but that's only if you don't start with a sample module source tree (which I made available 2 or 3 years ago.

http://hww3.riverweb.com/dist/pike_modules/SampleModule.tar.gz

Bill

On Aug 11, 2008, at 6:40 AM, Marcus Agehall (Roxen IS) @ Pike (-) developers forum wrote:

Currently, yes. But the old style module building framework pretty much assumed you were building a CMOD in general. If you didn't intend to do that, you still had to provide a few files which were more or less empty.

I think that was more of a design-flaw in the old-style method than anything else, but nevertheless...

I don't disagree that there are many more settings bundled than should be. That doesn't mean that the whole build system needs to be thrown out. The necessary changes could certainly be made without requiring that the currently built modules be rewritten to use the new build system.

The "new" build system doesn't really have any makefile or configure support at the current time, and as you've pointed out, doesn't seem to have tackled the splitting of things out yet.

My primary concern is that there's no qualification of the "new" way of doing things that it's not completely baked yet, and won't result in monger compatible modules (which I suspect is a large portion of what people are doing, outside of one-off personal projects).

Bill

On Aug 11, 2008, at 11:05 AM, Martin Stjernholm, Roxen IS @ Pike developers forum wrote:

The old system has a basic design flaw that way too many build settings come with pike and don't work where the module is compiled. As I understand it, that's difficult to fix in the old framework.

On the basic technical level it's clear how it should work: Settings that affect the ABI (some CFLAGS, a number of macros in machine.h, etc) should come with pike, but not anything else. There's really no room for choice as a matter of policy.

Then how to get there is a different matter. I seriously doubt the new system works correctly in this perspective either, because that'd require a deep split of machine.h - it contains both many ABI-defining macros and many configure test results. I haven't seen any hint of that getting sorted out, but I can confess that my knowledge of the external module building stuff is hazy.