Retargeting the installation and configuring options (eg --prefix, --with-*).
Detection of the build environment (eg compiler, system calls, etc).
Converting from a plain Makefile to configure.in+Makefile.in is straightforward if your Makefile already uses variables for binaries and directories.
The main reason to use autoconf is the second point above; when you write code that uses system calls (eg read(2), write(2)) and not libc calls (eg fread(3C), fwrite(3C)), that differ between operating systems (eg BSD vs SysV vs POSIX), and need to detect which taste you have.
To answer your questions: autoconf is something I hook in when:
the project is starting to get large,
when I've been bit by operating system incompatibilities,
Pike 7.4 seems to compile and link fine on Darwin 6.3 according to Pikefarm.
It also almost passes the testsuite, except for a 2 second sleep that slept 2.12 seconds (which may be due to load on the test machine).
I don't know of any reason why it wouldn't work fine on Darwin 1.4.
Most modules can be disabled by specifying --without-xxxx to configure. configure --help will list many of the supported flags. Some module specific options may however not be listed.
rntcl is an abbreviation of Remote NT CL (cl is M$'s compiler). rntcl works by controlling an NT machine through sprsh (Simple Pike Remote SHell) from a Unix machine.
Example: $ src/Pike/nt-tools/init_nt Using rc-file/home/grubba/.init_ntrc We are not Hubbe. NT kali $ uname -a Windows_NT kali 4.0 x86 NT kali $ cd src/Pike/7.5/build/NT/ NT kali $ ls -lF pike pike.exe -rwxr-xr-x 1 grubba grubba 315 Dec 27 12:01 pike* -rwxr--r-- 1 grubba grubba 6239657 Dec 27 12:01 pike.exe* NT kali $ cat pike #!/usr/local/bin/pike inherit "/home/grubba/src/Pike/nt-tools/tools/lib.pike"; int main(int argc, array(string) argv) { if (lower_case(getenv("CROSSCOMPILING")||"no") != "no") exit(1); argv[0]=getenv("NTDRIVE")+fixpath(follow_symlinks( combine_path(getcwd(),argv[0]))+".exe"); exit(silent_do_cmd(argv)); }
The sprsh system makes it possible to compile, link and run binaries on the remote NT system, but still have access to the full set of UNIX commands.
Building Pike on Cygwin is not (yet) supported as can be seen in Pikefarm.
Currently the only supported way of building Pike on WIN32/WIN64 systems is through rntcl. Hmm... It does however seem like nobody has released such a binary yet.
The reason is historical. The static keyword was inherited from C at a time when there was a one class/file limitation in the compiler. The interpretation was then similar to the interpretation of static for global symbols in object files.
NB: It wasn't until late 1996 there was a syntax in Pike for having multiple classes/file.
Slashdot Mirror
autoconf has two purposes:
Converting from a plain Makefile to configure.in+Makefile.in is straightforward if your Makefile already uses variables for binaries and directories.
The main reason to use autoconf is the second point above; when you write code that uses system calls (eg read(2), write(2)) and not libc calls (eg fread(3C), fwrite(3C)), that differ between operating systems (eg BSD vs SysV vs POSIX), and need to detect which taste you have.
To answer your questions: autoconf is something I hook in when:
So how do you portably detect which taste of system calls you have on the OS without autoconf, and without an explicit database OS <=> feature?
eg:
All of the above are easily detectable with autoconf.
I however agree with you that there's absolutely no need for automake.
Pike 7.4 seems to compile and link fine on Darwin 6.3 according to Pikefarm.
It also almost passes the testsuite, except for a 2 second sleep that slept 2.12 seconds (which may be due to load on the test machine).
I don't know of any reason why it wouldn't work fine on Darwin 1.4.
Most modules can be disabled by specifying --without-xxxx to configure. configure --help will list many of the supported flags. Some module specific options may however not be listed.
rntcl is an abbreviation of Remote NT CL (cl is M$'s compiler). rntcl works by controlling an NT machine through sprsh (Simple Pike Remote SHell) from a Unix machine.
Example: /home/grubba/.init_ntrc ( combine_path(getcwd(),argv[0]))+".exe");
$ src/Pike/nt-tools/init_nt
Using rc-file
We are not Hubbe.
NT kali $ uname -a
Windows_NT kali 4.0 x86
NT kali $ cd src/Pike/7.5/build/NT/
NT kali $ ls -lF pike pike.exe
-rwxr-xr-x 1 grubba grubba 315 Dec 27 12:01 pike*
-rwxr--r-- 1 grubba grubba 6239657 Dec 27 12:01 pike.exe*
NT kali $ cat pike
#!/usr/local/bin/pike
inherit "/home/grubba/src/Pike/nt-tools/tools/lib.pike";
int main(int argc, array(string) argv) {
if (lower_case(getenv("CROSSCOMPILING")||"no") != "no")
exit(1);
argv[0]=getenv("NTDRIVE")+fixpath(follow_symlinks
exit(silent_do_cmd(argv));
}
The sprsh system makes it possible to compile, link and run binaries on the remote NT system, but still have access to the full set of UNIX commands.
True.
The current status is:
Successful builds on:
Failures were noted for the following reasons:
So I wouldn't say that it only works on Linux/IA32...
Building Pike on Cygwin is not (yet) supported as can be seen in Pikefarm.
Currently the only supported way of building Pike on WIN32/WIN64 systems is through rntcl.
Hmm... It does however seem like nobody has released such a binary yet.
The reason is historical. The static keyword was inherited from C at a time when there was a one class/file limitation in the compiler. The interpretation was then similar to the interpretation of static for global symbols in object files.
NB: It wasn't until late 1996 there was a syntax in Pike for having multiple classes/file.
Apache? Not quite...
internal-roxen-roxen gives a hint...
Note that the above is the average over a ~2 month period (ie peek values are much higher).
Of course, I wouldn't want to run the above server with Apache or similar. :-)
Some version of Roxen 1.2 I assume.
BTW, see mvc-009f.jpg.