Coro/Coro/Makefile.PL

use 5.005;

use strict;
use ExtUtils::MakeMaker;
use Config;

$|=1;

my $DEFINE;
my @LIBS = [];

my $threads = $Config{usethreads};

print <<EOF;

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 

Coro has a number of configuration options. Due to its maturity, the
defaults that Coro chooses are usually fine, so you can decide to skip
these questions. Only if something went wrong you should select 'n'
here and manually configure Coro, and, of course, report this to the
maintainer :)

EOF

if (prompt ("Skip further questions and use defaults (y/n)?", "y") =~ /[yY]/) {
   $ENV{PERL_MM_USE_DEFAULT} = 1;
}


$DEFINE .= " -DHAVE_MMAP" if $Config{d_mmap} eq "define" && $Config{d_munmap} eq "define";

my $iface;

# default to assembly on x86 and x86_64 sometimes
my $iface_asm = $Config{archname} =~ /^(i[3456]86|amd64|x86_64)-/ ? "a" : undef;

if (exists $ENV{CORO_INTERFACE}) {
   $iface = $ENV{CORO_INTERFACE};

} elsif ($^O =~ /win32/i or $^O =~ /cygwin/ or $^O =~ /mswin/) {
   # nothing works, really, without deep hacks
   $iface = 'w';

} elsif ($^O =~ /irix/) {
   # sigaltstack works like sigstack, i.e. expects stack pointer, not stack base
   # but wikipeida lists it as 100% posix compliant. geeeee.
   $iface = "i";

} elsif ($^O =~ /linux/) {
   # everything "just works", as expected
   $iface = $iface_asm || "s";

} elsif ($^O =~ /freebsd/) {
   # FreeBSD 4.x has ucontext.h but no makecontext et al. (see BUGS section of
   # man context).
   #
   # FreeBSD 6.2 has marginally working ucontext, setjmp and asm, but
   # some 5.8.8's barf when threaded due to broken threading.

   $iface = $iface_asm || "s";

} elsif ($^O =~ /netbsd/) {
   # netbsd is totally broken (pthreads are incomaptible with ucontext or
   # other stack switching mechanisms) therefore, default to pthread -
   # hey, it might actually work, with some hacks
   $iface = "p";

} elsif ($^O =~ /(openbsd|mirbsd)/) {
   # openbsd:
   # asm seems to work, setjmp might, ucontext is missing, threads lets not talk about
   # try setjmp/longjmp on 4.4, but pthread on earlier
   # mirbsd:
   # seems to be bug-to-bug compatible openbsd fork,
   # with the name change being the biggest difference.
   $iface = $iface_asm || ($Config{osvers} >= 4.4 ? "s" : "p");

} elsif ($^O =~ /solaris/) {
   # setjmp, ucontext seem to work, as well as asm
   $iface = $iface_asm || "s";

} elsif ($^O =~ /darwin/) {
   # assembler doesn't support .type
   # ucontext is of course totally broken (it just crashes)
   # surprisingly, pthreads seem to work
   $iface = "s";

} elsif ($^O =~ /dragonfly/) {
   # ucontext is totally broken on dragonfly bsd:
   # Fatal error 'siglongjmp()ing between thread contexts is undefined by POSIX 1003.1
   $iface = "s";

} elsif (-e "/usr/include/ucontext.h") { # shame on this heuristic
   $iface = "u";

} else {
   $iface = "s";
}

print <<EOF;

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 

Coro can use a number of methods to implement coroutines at the C
level. The default chosen is based on your current confguration and is
correct in most cases, but you still can chose between these alternatives:

u  The unix 'ucontext.h' functions are relatively new and not implemented
   or well-tested in older unices. They allow very fast coroutine creation
   and reasonably fast switching.  They are, however, usually slower than
   the other alternatives due to an extra syscall done by swapcontext. And
   while nominally most portable (it's the only POSIX-standardised
   interface for coroutines), ucontext functions are, as usual, broken on
   most/all BSDs.

s  If the ucontext functions are not working or you don't want
   to use them for other reasons you can try a workaround using
   setjmp/longjmp/sigaltstack (also standard unix functions). Coroutine
   creation is rather slow, but switching is very fast (often much faster
   than with the ucontext functions). Unfortunately, glibc-2.1 and
   below don't even feature a working sigaltstack. You cannot use this
   implementation if some other code uses SIGUSR2 or you plan to create
   coroutines from an alternative signal stack, as both are being used for
   coroutine creation.

a  Handcoded assembly. This is the fastest and most compatible method,
   with the least side effects, if it works, that is. It has been tested
   on GNU/Linux x86 and x86_64 systems and should work on all x86/x86_64
   systems using the SVR ELF ABI (it is also reported to be working on
   Strawberry Perl for Windows using MinGW). This is the recommended
   method on supported platforms. When it doesn't work, use another
   method, such as (s)etjmp/longjmp.

l  GNU/Linux. Very old GNU/Linux systems (glibc-2.1 and below) need
   this hack. Since it is very linux-specific it is also quite fast and
   recommended even for newer versions; when it works, that is (currently
   x86 and a few others only. If it compiles, it's usually ok). Newer
   glibc versions (>= 2.5) stop working with this implementation however.

i  IRIX. For some reason, SGI really does not like to follow POSIX (does
   that surprise you?), so this workaround might be needed (it's fast),
   although [s] and [u] should also work now.

w  Microsoft Windows. Try this on Microsoft Windows when using Cygwin or
   the MSVC compilers (e.g. ActiveState Perl, but see "a" for Strawberry
   Perl), although, as there is no standard on how to do this under
   windows, different environments might work differently. Doh.

p  Use pthread API. Try to avoid this option, it was only created to
   make a point about the programming language shootout. It is unlikely
   to work with perls that have windows process emulation enabled ("perl
   threads"). It is also likely the slowest method of implementing
   coroutines. It might work fine as a last resort, however, as the
   pthread API is slightly better tested than ucontext functions for
   example. Of course, not on BSDs, who usually have very broken pthread
   implementations.

Coro tries hard to come up with a suitable default for most systems,
so pressing return at the prompt usually does the right thing. If you
experience problems (e.g. make test fails) then you should experiment with
this setting.

EOF

retry:

my $r = prompt "Use which implementation,\n" .
               "<s>et/longjump, <u>context, <a>ssembly, <i>rix, <l>inux or <w>indows?",
               $iface;
$iface = lc $1 if $r =~ /(\S)/;

if ($iface eq "u") {
   $DEFINE .= " -DCORO_UCONTEXT";
   print "\nUsing ucontext implementation\n\n";
   conftest ("TEST_makecontext");
} elsif ($iface eq "s") {
   $DEFINE .= " -DCORO_SJLJ";
   print "\nUsing setjmp/longjmp/sigaltstack implementation\n\n";
   conftest ("TEST_sigaltstack");
} elsif ($iface eq "l") {
   $DEFINE .= " -DCORO_LINUX";
   print "\nUsing linux-specific implementation\n\n";
} elsif ($iface eq "i") {
   $DEFINE .= " -DCORO_IRIX";
   print "\nUsing irix-specific implementation\n\n";
} elsif ($iface eq "w") {
   $DEFINE .= " -DCORO_LOSER";
   print "\nUsing windows-specific implementation\n\n";
} elsif ($iface eq "a") {
   $DEFINE .= " -DCORO_ASM";
   print "\nUsing handcoded assembly implementation\n\n";
} elsif ($iface eq "p") {
   $DEFINE .= " -DCORO_PTHREAD";
   @LIBS = ["-lpthread"];
   print "\nUsing pthread implementation\n\n";
} else {
   print "\nUnknown implementation \"$iface\"\n";
   goto retry;
}

print <<EOF;

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 

Per-context stack size factor: Depending on your settings, Coro tries to
share the C stacks is creates as much as possible, but sometimes it needs
to allocate a new one. This setting controls the maximum size that gets
allocated, and should not be set too high, as memory and address space
still is wasted even if it's not fully used. The value entered will be
multiplied by sizeof(long), which is usually 4 on 32-bit systems, and 8 on
64-bit systems.

A setting of 16384 (the default) therefore corresponds to a 64k..128k
stack, which usually is ample space (you might even want to try 8192 or
lower if your program creates many coroutines).

On systems supporting mmap and dynamic memory management, the actual
memory usually gets allocated on demand, but with many large stacks you
can still run out of address space on your typical 32 bit platform (not to
forget the pagetables).

Some perls (mostly threaded ones and perl compiled under linux 2.6) and
some programs (inefficient regexes can use a lot of stack space) may
need much, much more: If Coro segfaults with weird backtraces (e.g. in a
function prologue) or in t/10_bugs.t, you might want to increase this to
65536 or more.

The default should be fine, and can be changed at runtime with
Coro::State::cctx_stacksize.

EOF

my $stacksize = $^O eq "linux" && $] < 5.008008 ? 128 * 1024 : 16384;

$stacksize = prompt ("C stack size factor?", $stacksize);
$DEFINE .= " -DCORO_STACKSIZE=$stacksize";

print "using a stacksize of $stacksize * sizeof(long)\n";

print <<EOF;

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 

Coro can optionally put a guard area before each stack segment: When the
stack is too small and the access is not too far outside the stack (i.e.
within the guard area), then the program will safely segfault instead of
running into other data. The cost is some additional overhead with is
usually negligible, and extra use of address space.

The guard area size currently needs to be specified in pages (typical
pagesizes are 4k and 8k). The guard area is only enabled on a few
hardcoded architectures and is ignored on others. The actual preprocessor
expression disables this feature if:

   !__i386 && !__x86_64 && !__powerpc && !__m68k \
   && !__alpha && !__mips && !__sparc64

The default, as usual, should be just fine.

EOF

my $stackguard = prompt ("Number of guard pages (0 disables)?", "4");
$DEFINE .= " -DCORO_STACKGUARD=$stackguard";

print <<EOF;

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 

Coro can tell valgrind about its stacks and so reduce spurious warnings
where valgrind would otherwise complain about possible stack switches.

Enabling this does not incur noticable runtime or memory overhead, but it
requires that you have the <valgrind/valgrind.h> header file available.

Valgrind support is completely optional, so disabling it is the safe
choice.

EOF

my $valgrind = prompt ("Enable valgrind support (y/n)?",
                       -r "/usr/include/valgrind/valgrind.h" ?  "y" : "n");
$DEFINE .= " -DCORO_USE_VALGRIND=1" if $valgrind =~ /[yY]/;


print <<EOF;

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 

Coro can use (or even trick) some perl functions into doing what it needs
instead of relying on (some) of its own functions. This might increase
chances that it compiles and works, but it could just as well result in
memory leaks, crashes or silent data corruption. It certainly does result
in slightly slower speed and higher memory consumption, though, so YOU
SHOULD ENABLE THIS OPTION ONLY AS A LAST RESORT.

EOF

my $use_internals = prompt ("Prefer perl functions over coro functions (y/n)?", "n");
$DEFINE .= " -DCORO_PREFER_PERL_FUNCTIONS=1" if $use_internals =~ /[yY]/;

print <<EOF;

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 

Coro has experimental support for cloning states. This can be used
to implement a scheme-like call/cc. However, this doesn't add to the
expressiveness in general, and is likely perl-version specific. As such,
it is disabled by default.  Enable it when you want to play around with
it, but note that it isn't supported, and unlikely ever will be. It
exists mainly to prove that it could be done - if only it were useful for
something.

EOF

my $masturbate = $ENV{CORO_CLONE} || "n";
$masturbate = prompt ("Implement Coro::State->clone method (y/n)?", $masturbate);
$DEFINE .= " -DCORO_CLONE=1" if $masturbate =~ /[yY]/;

print <<EOF;

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 

EOF

WriteMakefile(
  NAME         => "Coro::State",
  VERSION_FROM => "State.pm",
  DEFINE       => $DEFINE,
  LIBS         => @LIBS,
  DIR          => [],
  depend => {
     "State.c" => "state.h clone.c libcoro/coro.h libcoro/coro.c",
  },
);

sub conftest {
   my $type = shift;

   print "\nTrying to detect stack growth direction (for $type)\n";
   print "You might see some warnings, this should not concern you.\n\n";
   system "$Config{cc} $Config{ccflags} -D$type libcoro/conftest.c";

   my $res = qx<./a.out>;
   $res =~ s/\s+$//;
   my ($sp, $ss) = split /,/, $res;

   print "\n\n*****************************************************************************\n";
   print "If the testsuite fails PLEASE provide the following information\n";
   print "to Marc Lehmann <schmorp\@schmorp.de>: operating system name, version,\n";
   print "architecture name and this string '$sp|$ss'. Thanks a lot!\n";#d#
   print "*****************************************************************************\n\n";

   unlink "a.out";
   unlink "conftestval";
}

Revision:	1.73
Committed:	Thu Dec 4 17:29:40 2008 UTC (15 years, 6 months ago) by root
Content type:	text/plain
Branch:	MAIN
CVS Tags:	rel-5_151, rel-6_13, rel-5_161, rel-5_12, rel-5_15, rel-5_14, rel-5_16, rel-5_132, rel-5_131
Changes since 1.72:	+6 -6 lines
Log Message:	* empty log message *
#	User	Rev	Content
1	root	1.7	use 5.005;
2	root	1.1
3	root	1.55	use strict;
4			use ExtUtils::MakeMaker;
5	root	1.2	use Config;
6
7	root	1.6	$\|=1;
8
9	root	1.55	my $DEFINE;
10			my @LIBS = [];
11	root	1.2
12	root	1.69	my $threads = $Config{usethreads};
13	root	1.57
14	root	1.44	print <<EOF;
15
16			* * * * * * * * * * * * * * * * * *
17
18			Coro has a number of configuration options. Due to its maturity, the
19			defaults that Coro chooses are usually fine, so you can decide to skip
20			these questions. Only if something went wrong you should select 'n'
21			here and manually configure Coro, and, of course, report this to the
22			maintainer :)
23
24			EOF
25
26	root	1.45	if (prompt ("Skip further questions and use defaults (y/n)?", "y") =~ /[yY]/) {
27	root	1.44	$ENV{PERL_MM_USE_DEFAULT} = 1;
28			}
29
30
31	root	1.2	$DEFINE .= " -DHAVE_MMAP" if $Config{d_mmap} eq "define" && $Config{d_munmap} eq "define";
32
33	root	1.55	my $iface;
34
35	root	1.65	# default to assembly on x86 and x86_64 sometimes
36			my $iface_asm = $Config{archname} =~ /^(i[3456]86\|amd64\|x86_64)-/ ? "a" : undef;
37
38	root	1.49	if (exists $ENV{CORO_INTERFACE}) {
39			$iface = $ENV{CORO_INTERFACE};
40	root	1.50
41	root	1.49	} elsif ($^O =~ /win32/i or $^O =~ /cygwin/ or $^O =~ /mswin/) {
42	root	1.69	# nothing works, really, without deep hacks
43	root	1.34	$iface = 'w';
44	root	1.50
45	root	1.14	} elsif ($^O =~ /irix/) {
46	root	1.69	# sigaltstack works like sigstack, i.e. expects stack pointer, not stack base
47			# but wikipeida lists it as 100% posix compliant. geeeee.
48	root	1.14	$iface = "i";
49	root	1.50
50	root	1.4	} elsif ($^O =~ /linux/) {
51	root	1.69	# everything "just works", as expected
52	root	1.65	$iface = $iface_asm \|\| "s";
53	root	1.48
54	root	1.65	} elsif ($^O =~ /freebsd/) {
55	root	1.40	# FreeBSD 4.x has ucontext.h but no makecontext et al. (see BUGS section of
56	root	1.69	# man context).
57	root	1.65	#
58	root	1.69	# FreeBSD 6.2 has marginally working ucontext, setjmp and asm, but
59	root	1.68	# some 5.8.8's barf when threaded due to broken threading.
60	root	1.65
61			$iface = $iface_asm \|\| "s";
62	root	1.50
63	root	1.65	} elsif ($^O =~ /netbsd/) {
64	root	1.69	# netbsd is totally broken (pthreads are incomaptible with ucontext or
65			# other stack switching mechanisms) therefore, default to pthread -
66			# hey, it might actually work, with some hacks
67	root	1.62	$iface = "p";
68	root	1.50
69	root	1.73	} elsif ($^O =~ /(openbsd\|mirbsd)/) {
70			# openbsd:
71	root	1.69	# asm seems to work, setjmp might, ucontext is missing, threads lets not talk about
72	root	1.73	# try setjmp/longjmp on 4.4, but pthread on earlier
73			# mirbsd:
74	root	1.71	# seems to be bug-to-bug compatible openbsd fork,
75	root	1.73	# with the name change being the biggest difference.
76			$iface = $iface_asm \|\| ($Config{osvers} >= 4.4 ? "s" : "p");
77	root	1.71
78	root	1.8	} elsif ($^O =~ /solaris/) {
79	root	1.66	# setjmp, ucontext seem to work, as well as asm
80			$iface = $iface_asm \|\| "s";
81	root	1.50
82	root	1.25	} elsif ($^O =~ /darwin/) {
83	root	1.69	# assembler doesn't support .type
84			# ucontext is of course totally broken (it just crashes)
85			# surprisingly, pthreads seem to work
86	root	1.25	$iface = "s";
87	root	1.50
88	root	1.60	} elsif ($^O =~ /dragonfly/) {
89			# ucontext is totally broken on dragonfly bsd:
90			# Fatal error 'siglongjmp()ing between thread contexts is undefined by POSIX 1003.1
91			$iface = "s";
92
93	root	1.40	} elsif (-e "/usr/include/ucontext.h") { # shame on this heuristic
94	root	1.3	$iface = "u";
95	root	1.50
96	root	1.2	} else {
97	root	1.3	$iface = "s";
98	root	1.2	}
99
100	root	1.44	print <<EOF;
101	root	1.2
102	root	1.38	* * * * * * * * * * * * * * * * * *
103
104	root	1.40	Coro can use a number of methods to implement coroutines at the C
105			level. The default chosen is based on your current confguration and is
106			correct in most cases, but you still can chose between these alternatives:
107	root	1.34
108			u The unix 'ucontext.h' functions are relatively new and not implemented
109	root	1.48	or well-tested in older unices. They allow very fast coroutine creation
110	root	1.63	and reasonably fast switching. They are, however, usually slower than
111			the other alternatives due to an extra syscall done by swapcontext. And
112			while nominally most portable (it's the only POSIX-standardised
113			interface for coroutines), ucontext functions are, as usual, broken on
114			most/all BSDs.
115	root	1.4
116			s If the ucontext functions are not working or you don't want
117	root	1.48	to use them for other reasons you can try a workaround using
118			setjmp/longjmp/sigaltstack (also standard unix functions). Coroutine
119	root	1.49	creation is rather slow, but switching is very fast (often much faster
120			than with the ucontext functions). Unfortunately, glibc-2.1 and
121			below don't even feature a working sigaltstack. You cannot use this
122	root	1.63	implementation if some other code uses SIGUSR2 or you plan to create
123			coroutines from an alternative signal stack, as both are being used for
124			coroutine creation.
125	root	1.49
126	root	1.63	a Handcoded assembly. This is the fastest and most compatible method,
127	root	1.53	with the least side effects, if it works, that is. It has been tested
128			on GNU/Linux x86 and x86_64 systems and should work on all x86/x86_64
129	root	1.56	systems using the SVR ELF ABI (it is also reported to be working on
130			Strawberry Perl for Windows using MinGW). This is the recommended
131	root	1.63	method on supported platforms. When it doesn't work, use another
132			method, such as (s)etjmp/longjmp.
133	root	1.4
134	root	1.38	l GNU/Linux. Very old GNU/Linux systems (glibc-2.1 and below) need
135	root	1.48	this hack. Since it is very linux-specific it is also quite fast and
136			recommended even for newer versions; when it works, that is (currently
137			x86 and a few others only. If it compiles, it's usually ok). Newer
138	root	1.63	glibc versions (>= 2.5) stop working with this implementation however.
139	root	1.14
140	root	1.63	i IRIX. For some reason, SGI really does not like to follow POSIX (does
141			that surprise you?), so this workaround might be needed (it's fast),
142			although [s] and [u] should also work now.
143	root	1.2
144	root	1.56	w Microsoft Windows. Try this on Microsoft Windows when using Cygwin or
145			the MSVC compilers (e.g. ActiveState Perl, but see "a" for Strawberry
146			Perl), although, as there is no standard on how to do this under
147	root	1.58	windows, different environments might work differently. Doh.
148	root	1.34
149	root	1.64	p Use pthread API. Try to avoid this option, it was only created to
150			make a point about the programming language shootout. It is unlikely
151			to work with perls that have windows process emulation enabled ("perl
152			threads"). It is also likely the slowest method of implementing
153			coroutines. It might work fine as a last resort, however, as the
154			pthread API is slightly better tested than ucontext functions for
155			example. Of course, not on BSDs, who usually have very broken pthread
156			implementations.
157	root	1.63
158			Coro tries hard to come up with a suitable default for most systems,
159			so pressing return at the prompt usually does the right thing. If you
160			experience problems (e.g. make test fails) then you should experiment with
161			this setting.
162	root	1.28
163	root	1.2	EOF
164	root	1.3
165			retry:
166	root	1.14
167	root	1.44	my $r = prompt "Use which implementation,\n" .
168	root	1.49	"<s>et/longjump, <u>context, <a>ssembly, <i>rix, <l>inux or <w>indows?",
169	root	1.44	$iface;
170			$iface = lc $1 if $r =~ /(\S)/;
171
172			if ($iface eq "u") {
173			$DEFINE .= " -DCORO_UCONTEXT";
174			print "\nUsing ucontext implementation\n\n";
175	root	1.58	conftest ("TEST_makecontext");
176	root	1.44	} elsif ($iface eq "s") {
177			$DEFINE .= " -DCORO_SJLJ";
178			print "\nUsing setjmp/longjmp/sigaltstack implementation\n\n";
179	root	1.58	conftest ("TEST_sigaltstack");
180	root	1.44	} elsif ($iface eq "l") {
181			$DEFINE .= " -DCORO_LINUX";
182			print "\nUsing linux-specific implementation\n\n";
183			} elsif ($iface eq "i") {
184			$DEFINE .= " -DCORO_IRIX";
185			print "\nUsing irix-specific implementation\n\n";
186			} elsif ($iface eq "w") {
187			$DEFINE .= " -DCORO_LOSER";
188			print "\nUsing windows-specific implementation\n\n";
189	root	1.49	} elsif ($iface eq "a") {
190			$DEFINE .= " -DCORO_ASM";
191			print "\nUsing handcoded assembly implementation\n\n";
192	root	1.55	} elsif ($iface eq "p") {
193			$DEFINE .= " -DCORO_PTHREAD";
194			@LIBS = ["-lpthread"];
195			print "\nUsing pthread implementation\n\n";
196	root	1.3	} else {
197	root	1.44	print "\nUnknown implementation \"$iface\"\n";
198			goto retry;
199	root	1.3	}
200	root	1.2
201	root	1.36	print <<EOF;
202
203	root	1.38	* * * * * * * * * * * * * * * * * *
204
205			Per-context stack size factor: Depending on your settings, Coro tries to
206	root	1.58	share the C stacks is creates as much as possible, but sometimes it needs
207			to allocate a new one. This setting controls the maximum size that gets
208			allocated, and should not be set too high, as memory and address space
209			still is wasted even if it's not fully used. The value entered will be
210			multiplied by sizeof(long), which is usually 4 on 32-bit systems, and 8 on
211			64-bit systems.
212	root	1.37
213	root	1.38	A setting of 16384 (the default) therefore corresponds to a 64k..128k
214	root	1.40	stack, which usually is ample space (you might even want to try 8192 or
215	root	1.38	lower if your program creates many coroutines).
216	root	1.37
217	root	1.41	On systems supporting mmap and dynamic memory management, the actual
218			memory usually gets allocated on demand, but with many large stacks you
219	root	1.58	can still run out of address space on your typical 32 bit platform (not to
220			forget the pagetables).
221	root	1.41
222	root	1.40	Some perls (mostly threaded ones and perl compiled under linux 2.6) and
223			some programs (inefficient regexes can use a lot of stack space) may
224			need much, much more: If Coro segfaults with weird backtraces (e.g. in a
225			function prologue) or in t/10_bugs.t, you might want to increase this to
226			65536 or more.
227	root	1.36
228	root	1.47	The default should be fine, and can be changed at runtime with
229			Coro::State::cctx_stacksize.
230	root	1.41
231	root	1.36	EOF
232
233	root	1.67	my $stacksize = $^O eq "linux" && $] < 5.008008 ? 128 * 1024 : 16384;
234
235			$stacksize = prompt ("C stack size factor?", $stacksize);
236	root	1.46	$DEFINE .= " -DCORO_STACKSIZE=$stacksize";
237	root	1.36
238			print "using a stacksize of $stacksize * sizeof(long)\n";
239
240	root	1.38	print <<EOF;
241
242			* * * * * * * * * * * * * * * * * *
243
244	root	1.58	Coro can optionally put a guard area before each stack segment: When the
245	root	1.41	stack is too small and the access is not too far outside the stack (i.e.
246			within the guard area), then the program will safely segfault instead of
247			running into other data. The cost is some additional overhead with is
248			usually negligible, and extra use of address space.
249
250			The guard area size currently needs to be specified in pages (typical
251			pagesizes are 4k and 8k). The guard area is only enabled on a few
252			hardcoded architectures and is ignored on others. The actual preprocessor
253			expression disables this feature if:
254
255			!__i386 && !__x86_64 && !__powerpc && !__m68k \
256			&& !__alpha && !__mips && !__sparc64
257
258			The default, as usual, should be just fine.
259
260			EOF
261
262	root	1.45	my $stackguard = prompt ("Number of guard pages (0 disables)?", "4");
263	root	1.46	$DEFINE .= " -DCORO_STACKGUARD=$stackguard";
264	root	1.41
265			print <<EOF;
266
267			* * * * * * * * * * * * * * * * * *
268
269	root	1.43	Coro can tell valgrind about its stacks and so reduce spurious warnings
270			where valgrind would otherwise complain about possible stack switches.
271
272	root	1.58	Enabling this does not incur noticable runtime or memory overhead, but it
273	root	1.43	requires that you have the <valgrind/valgrind.h> header file available.
274
275	root	1.58	Valgrind support is completely optional, so disabling it is the safe
276			choice.
277	root	1.43
278			EOF
279
280	root	1.45	my $valgrind = prompt ("Enable valgrind support (y/n)?",
281	root	1.44	-r "/usr/include/valgrind/valgrind.h" ? "y" : "n");
282	root	1.46	$DEFINE .= " -DCORO_USE_VALGRIND=1" if $valgrind =~ /[yY]/;
283	root	1.43
284	root	1.44
285			print <<EOF;
286
287			* * * * * * * * * * * * * * * * * *
288
289			Coro can use (or even trick) some perl functions into doing what it needs
290			instead of relying on (some) of its own functions. This might increase
291			chances that it compiles and works, but it could just as well result in
292			memory leaks, crashes or silent data corruption. It certainly does result
293	root	1.51	in slightly slower speed and higher memory consumption, though, so YOU
294	root	1.58	SHOULD ENABLE THIS OPTION ONLY AS A LAST RESORT.
295	root	1.44
296			EOF
297
298	root	1.45	my $use_internals = prompt ("Prefer perl functions over coro functions (y/n)?", "n");
299	root	1.46	$DEFINE .= " -DCORO_PREFER_PERL_FUNCTIONS=1" if $use_internals =~ /[yY]/;
300	root	1.44
301	root	1.43	print <<EOF;
302
303			* * * * * * * * * * * * * * * * * *
304
305	root	1.70	Coro has experimental support for cloning states. This can be used
306			to implement a scheme-like call/cc. However, this doesn't add to the
307			expressiveness in general, and is likely perl-version specific. As such,
308			it is disabled by default. Enable it when you want to play around with
309	root	1.72	it, but note that it isn't supported, and unlikely ever will be. It
310	root	1.70	exists mainly to prove that it could be done - if only it were useful for
311			something.
312
313			EOF
314
315			my $masturbate = $ENV{CORO_CLONE} \|\| "n";
316			$masturbate = prompt ("Implement Coro::State->clone method (y/n)?", $masturbate);
317			$DEFINE .= " -DCORO_CLONE=1" if $masturbate =~ /[yY]/;
318
319			print <<EOF;
320
321			* * * * * * * * * * * * * * * * * *
322
323	root	1.38	EOF
324	root	1.36
325	root	1.1	WriteMakefile(
326	root	1.2	NAME => "Coro::State",
327			VERSION_FROM => "State.pm",
328			DEFINE => $DEFINE,
329	root	1.55	LIBS => @LIBS,
330	root	1.2	DIR => [],
331	root	1.62	depend => {
332	root	1.70	"State.c" => "state.h clone.c libcoro/coro.h libcoro/coro.c",
333	root	1.62	},
334	root	1.1	);
335	root	1.2
336	root	1.15	sub conftest {
337			my $type = shift;
338
339			print "\nTrying to detect stack growth direction (for $type)\n";
340			print "You might see some warnings, this should not concern you.\n\n";
341			system "$Config{cc} $Config{ccflags} -D$type libcoro/conftest.c";
342
343			my $res = qx<./a.out>;
344			$res =~ s/\s+$//;
345			my ($sp, $ss) = split /,/, $res;
346
347			print "\n\n*****************************************************************************\n";
348			print "If the testsuite fails PLEASE provide the following information\n";
349	root	1.32	print "to Marc Lehmann <schmorp\@schmorp.de>: operating system name, version,\n";
350	root	1.15	print "architecture name and this string '$sp\|$ss'. Thanks a lot!\n";#d#
351			print "*****************************************************************************\n\n";
352
353			unlink "a.out";
354	root	1.17	unlink "conftestval";
355	root	1.15	}
356	root	1.2