Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[perl #37178] [PATCH] Quiet a few alignment warnings

4 views
Skip to first unread message

Will Coleda via RT

unread,
Mar 14, 2007, 11:30:48 PM3/14/07
to perl6-i...@perl.org
Thanks, (belatedly) applied.

Andy Dougherty

unread,
Mar 19, 2007, 11:19:41 AM3/19/07
to Will Coleda via RT
On Wed, 14 Mar 2007, Will Coleda via RT wrote:

> Re: [perl #37178] [PATCH] Quiet a few alignment warnings

> Thanks, (belatedly) applied.

Wow. I'd completely given up hope on that one.

So feeling inspired, I decided to try it out and see how things looked.
Alas, my first attempt failed:

$ rsync -av --delete svn.perl.org::parrot-HEAD parrot-current
failed to connect to svn.perl.org - Connection refused

I then tried fetching a snapshot. That seemed to work. There doesn't seem
to be an obvious way to get the svn revision number out of it, but
here's the timestamp:

$ cat .timestamp
1174288505
Mon Mar 19 07:15:05 2007 UTC

(time of this svn update)

This one falls over immediately during Configure. Even setting
verbose=2, I don't see why:

Parrot Version 0.4.9 Configure 2.0
Copyright (C) 2001-2007, The Perl Foundation.

[ . . . ]

Determining what C compiler and linker to use...
No compiler found (tried 'cc')

Yet 'cc' works perfectly fine, and has for years. I have changed
nothing in my build scripts.

Oh well, back to other work instead. Thanks for applying my patch,
though. Maybe someone else will pick up the task and try to document
and check parrot's alignment assumptions

--
Andy Dougherty doug...@lafayette.edu

Chromatic

unread,
Mar 19, 2007, 6:32:21 PM3/19/07
to perl6-i...@perl.org, Andy Dougherty, Will Coleda via RT
On Monday 19 March 2007 11:56, Andy Dougherty wrote:

> On Mon, 19 Mar 2007, chromatic wrote:

> > The heuristic for detecting a compiler is to invoke it with some sort of
> > help flag, where $cc contains the executable name of your compiler:
> >
> > $cc -h
> > $cc --help
> > $cc /?
> >
> > If there's another option to pass to your compiler that causes it to do
> > nothing except exit with a successful error code, we can put it in there.
> > (Checking $ENV{PATH} and trying to divine the proper extension is another
> > option, but I like that one a little less.)

> In my opinion, that way lies madness. Generating a list of options which
> all possible current and future compilers will accept is not only
> impossible, it's pointless. It's also aggravating that there's no way to
> override it or tell Configure "Yes, cc is my compiler even though it's not
> in your list."
>
> The only way to tell for sure if you have a working compiler is to try to
> compile and run something. After the user has been prompted for all the
> flags, simply try to compile and run a simple test program. If it works,
> fine. If it doesn't, then complain with an informative error message. (It
> may be appropriate to skip the 'run' step in a cross-compilation
> environment and hope that the user got the flags right if the compilation
> succeeds.)

What's the minimally-useful, cross-platform way to compile, link, and run:

int main() {
return 0;
}

I'm happy to make the change, but I spent the weekend struggling to figure out
how MSVC handles shared libraries, and I'm no longer sure that the easy
approach is that easy.

-- c

Andy Dougherty

unread,
Mar 19, 2007, 2:56:03 PM3/19/07
to Perl6 Internals, Will Coleda via RT
On Mon, 19 Mar 2007, chromatic wrote:

> On Monday 19 March 2007 08:19, Andy Dougherty wrote:
>
> > This one falls over immediately during Configure. Even setting
> > verbose=2, I don't see why:
> >
> > Parrot Version 0.4.9 Configure 2.0
> > Copyright (C) 2001-2007, The Perl Foundation.
> >
> > [ . . . ]
> >
> > Determining what C compiler and linker to use...
> > No compiler found (tried 'cc')
> >
> > Yet 'cc' works perfectly fine, and has for years. I have changed
> > nothing in my build scripts.
>

> The heuristic for detecting a compiler is to invoke it with some sort of help
> flag, where $cc contains the executable name of your compiler:
>
> $cc -h
> $cc --help
> $cc /?
>
> If there's another option to pass to your compiler that causes it to do
> nothing except exit with a successful error code, we can put it in there.
> (Checking $ENV{PATH} and trying to divine the proper extension is another
> option, but I like that one a little less.)

In my opinion, that way lies madness. Generating a list of options which
all possible current and future compilers will accept is not only
impossible, it's pointless. It's also aggravating that there's no way to
override it or tell Configure "Yes, cc is my compiler even though it's not
in your list."

The only way to tell for sure if you have a working compiler is to try to
compile and run something. After the user has been prompted for all the
flags, simply try to compile and run a simple test program. If it works,
fine. If it doesn't, then complain with an informative error message. (It
may be appropriate to skip the 'run' step in a cross-compilation
environment and hope that the user got the flags right if the compilation
succeeds.)

--
Andy Dougherty doug...@lafayette.edu

Andy Dougherty

unread,
Mar 19, 2007, 3:22:20 PM3/19/07
to Perl6 Internals, Will Coleda via RT
I found the ticket that introduced this failing behavior, so I'm resending
my message below with a fixed-up subject line to enter into RT. In brief,
this patch incorrectly assumes that all compilers accept a '-h', '--help',
or '/?' switch. Any compiler that doesn't is deemed 'not found', and
there is no way to override it. Extending the list of options to try is
not a sensible forward-looking portable strategy.

Chromatic

unread,
Mar 19, 2007, 2:06:01 PM3/19/07
to perl6-i...@perl.org, Andy Dougherty, Will Coleda via RT
On Monday 19 March 2007 08:19, Andy Dougherty wrote:

> This one falls over immediately during Configure. Even setting
> verbose=2, I don't see why:
>
> Parrot Version 0.4.9 Configure 2.0
> Copyright (C) 2001-2007, The Perl Foundation.
>
> [ . . . ]
>
> Determining what C compiler and linker to use...
> No compiler found (tried 'cc')
>
> Yet 'cc' works perfectly fine, and has for years. I have changed
> nothing in my build scripts.

The heuristic for detecting a compiler is to invoke it with some sort of help

flag, where $cc contains the executable name of your compiler:

$cc -h
$cc --help
$cc /?

If there's another option to pass to your compiler that causes it to do
nothing except exit with a successful error code, we can put it in there.
(Checking $ENV{PATH} and trying to divine the proper extension is another
option, but I like that one a little less.)

-- c

Chromatic

unread,
Mar 19, 2007, 6:58:39 PM3/19/07
to perl6-i...@perl.org, Andy Dougherty, Will Coleda via RT
On Monday 19 March 2007 12:22, Andy Dougherty wrote:

> I found the ticket that introduced this failing behavior, so I'm resending
> my message below with a fixed-up subject line to enter into RT. In brief,
> this patch incorrectly assumes that all compilers accept a '-h', '--help',
> or '/?' switch. Any compiler that doesn't is deemed 'not found', and
> there is no way to override it. Extending the list of options to try is
> not a sensible forward-looking portable strategy.

I realize this patch precludes cross-compilation at the moment, but does it
work better for you, Andy?

-- c

better_compiler_detection.patch

Nicholas Clark

unread,
Mar 19, 2007, 6:30:56 PM3/19/07
to Andy Dougherty, Perl6 Internals, Will Coleda via RT
On Mon, Mar 19, 2007 at 02:56:03PM -0400, Andy Dougherty wrote:

> In my opinion, that way lies madness. Generating a list of options which
> all possible current and future compilers will accept is not only
> impossible, it's pointless. It's also aggravating that there's no way to
> override it or tell Configure "Yes, cc is my compiler even though it's not
> in your list."

It's like Inline::C telling me that $Config{cc} doesn't appear to be a
compiler. Yes, you can't find "ccache cc" down my $PATH, but if you try
executing it, you'll find that it works just fine.

> The only way to tell for sure if you have a working compiler is to try to
> compile and run something. After the user has been prompted for all the
> flags, simply try to compile and run a simple test program. If it works,
> fine. If it doesn't, then complain with an informative error message. (It
> may be appropriate to skip the 'run' step in a cross-compilation
> environment and hope that the user got the flags right if the compilation
> succeeds.)

int main() {
return 0;
}

being a fairly good minimal example. I think that it's legal C++ too.

IIRC

main;

was found to be the shortest portable crash. :-)

Nicholas Clark

Andy Dougherty

unread,
Mar 20, 2007, 9:19:56 AM3/20/07
to chromatic, Perl6 Internals, Will Coleda via RT
> On Monday 19 March 2007 11:56, Andy Dougherty wrote:
>
> > The only way to tell for sure if you have a working compiler is to try to
> > compile and run something. After the user has been prompted for all the
> > flags, simply try to compile and run a simple test program. If it works,
> > fine. If it doesn't, then complain with an informative error message. (It
> > may be appropriate to skip the 'run' step in a cross-compilation
> > environment and hope that the user got the flags right if the compilation
> > succeeds.)

You can probably get by with whatever scheme is currently used to compile,
link, and run all the other tests in Configure, such as those to determine
sizeof(opcode_t) and the like. Perl 5's Configure uses the following
program:

#include <stdio.h>
int main() { printf("Ok\n"); return(0); }

The program includes output, and Configure tests for that output, because
we ran into cases where the program would compile, run, return a 'success'
exit value, but wouldn't actually print anything. The underlying problem
turned out to be a bug in SFIO's "iffe" configuration script (dealing with
_exit vs. exit, and the flushing of output buffers). So our "sanity" test
was expanded to include testing whether or not the program actually
printed what it was supposed to print.

--
Andy Dougherty doug...@lafayette.edu

Andrew Dougherty

unread,
Mar 20, 2007, 3:25:12 PM3/20/07
to chromatic, perl6-i...@perl.org, Andy Dougherty, Will Coleda via RT
On Mon, 19 Mar 2007, chromatic wrote:

Alas, no. Here's what I get (again with --verbose=2). I don't know why
it's reporting that the compiler is failling, and I don't know how to
coax Configure to give me any more information (short of sprinking
printf()s throughout).

I can definitely compile that test program with the indicated flags. I
don't have time to look at this further, however.

Determining what C compiler and linker to use...

Setting Configuration Data:
(
cc => 'cc',
);
Setting Configuration Data:
(
link => 'cc',
);
Setting Configuration Data:
(
ld => 'cc',
);
Setting Configuration Data:
(
ccflags => '-I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
);
Setting Configuration Data:
(
linkflags => ' -L/usr/local/lib -R/usr/local/lib ',
);
Setting Configuration Data:
(
ldflags => ' -L/usr/local/lib -R/usr/local/lib ',
);
Setting Configuration Data:
(
libs => '-lsocket -lnsl -ldl -lm',
);
Setting Configuration Data:
(
cxx => 'c++',
);
Setting Configuration Data:
(
cc_debug => '',
link_debug => '',
ld_debug => '',
);
Setting Configuration Data:
(
ccwarn => '',
);
cc -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I./include -c test.c
Compilation failed with 'cc'

--
Andy Dougherty doug...@lafayette.edu

Paul Cochrane via RT

unread,
Mar 20, 2007, 4:14:18 PM3/20/07
to perl6-i...@perl.org
On Tue Mar 20 12:13:15 2007, coke wrote:
> per chromatic, this should probably be backed out. At least for the
> 0.4.10 release.

Backed out until we find another solution to the problem.

Paul

Chromatic

unread,
Mar 20, 2007, 5:35:04 PM3/20/07
to Andrew Dougherty, perl6-i...@perl.org, Will Coleda via RT
On Tuesday 20 March 2007 12:25, Andrew Dougherty wrote:

> On Mon, 19 Mar 2007, chromatic wrote:

> > I realize this patch precludes cross-compilation at the moment, but does
> > it work better for you, Andy?
>
> Alas, no. Here's what I get (again with --verbose=2). I don't know why
> it's reporting that the compiler is failling, and I don't know how to
> coax Configure to give me any more information (short of sprinking
> printf()s throughout).
>
> I can definitely compile that test program with the indicated flags. I
> don't have time to look at this further, however.

Alright, I'll work on a better patch. We've pulled the previous one from the
upcoming release.

-- c

Andy Dougherty

unread,
Mar 21, 2007, 10:57:01 AM3/21/07
to chromatic, Perl6 Internals, Will Coleda via RT

Ok. I've figured out what was going wrong:

+ unless ( eval { cc_build(); 1 } ) {
+ warn "Compilation failed with '$cc'\n";
+ exit 1;
+ }

This has two problems. First, it ignores the return value of cc_build().
That's understandable at the moment since cc_build doesn't seem to have a
documented return value. It should, of course.

The second problem is that this construct doesn't check for other errors
in the eval. Putting in C< warn $@ if $@;> reveals the problem:

Determining what C compiler and linker to use...Unknown open() mode '>&'
at lib/Parrot/Configure/Step.pm line 437.

Configure/Step.pm is apparently using a 3-arg open construct not
understood by my perl-5.6.2 version. But according to README:

You'll also need Perl 5.6.1 or above to run various configure and
build scripts.

The README is also consistent with this line in Configure.pl:

use 5.006_001;

So all that needs to be straightened out somehow, either by changing the
3-arg opens or by upping the perl version requirement.

Moving on:

+ unless ( eval { cc_run(); 1 } ) {
+ warn $@ if $@;
+ exit 1;
+ }

This also has the same ignoring-error return problem, but it's more
serious. If the program runs but fails (e.g. segfaults, or returns a
non-zero status) this bit of code happily continues on. I think it
probably shouldn't under such circumstances.

Of course, even after fixing those things, it still doesn't even come
close to working. More about that tomorrow as I try to sort out all the
other problems. Sigh.

--
Andy Dougherty doug...@lafayette.edu

Paul Cochrane via RT

unread,
Sep 12, 2007, 9:00:56 AM9/12/07
to perl6-i...@perl.org

Applied the patch with some modifications so that it runs correctly on
Windows in r21212. Tested on Linux x86, Windows and Cygwin.

Paul


Paul Cochrane via RT

unread,
Sep 12, 2007, 10:13:01 AM9/12/07
to perl6-i...@perl.org

I've managed to test this on Solaris and it works if one doesn't specify
a bogus compiler. However, if one does specify a bogus compiler for
instance by using the configure line:

perl Configure.pl --cc=moo

then for some reason the configuration with solaris continues, even
though it should barf. The problem exists around line 39 in
config/init/hints/solaris.pm. If one tries C<exit 1;> if the
C<run_command> call doesn't work, then configure just happily continues
configuring. How does one get configure to stop completely at this
point??? Using plain C<exit 1;> on Linux, Windows and Cygwin worked fine.

Paul


Andy Dougherty

unread,
Sep 12, 2007, 11:25:06 AM9/12/07
to Paul Cochrane via RT, Perl6 Internals

But did you actually address any of my objections? For example, do you
now pay attention to exit codes? Do cc_build and cc_run now have exit
codes?

--
Andy Dougherty doug...@lafayette.edu

Paul Cochrane

unread,
Sep 13, 2007, 5:15:02 AM9/13/07
to Andy Dougherty, Paul Cochrane via RT, Perl6 Internals

The short answer here is: no. However attention to exit codes, and
exit codes from cc_build and cc_run are separate issues, aren't they?

A better thing to find out here is if parrot builds for you on your
platform. Does the current revision work for you? Then we can close
this ticket, and I'll open new tickets concerning exit codes from
cc_build and cc_run etc.

Paul

Paul Cochrane via RT

unread,
Sep 13, 2007, 6:01:20 AM9/13/07
to perl6-i...@perl.org
On Thu Sep 13 02:16:12 2007, ptc wrote:
> > > Applied the patch with some modifications so that it runs
> correctly on
> > > Windows in r21212. Tested on Linux x86, Windows and Cygwin.
> >
> > But did you actually address any of my objections? For example, do
> you
> > now pay attention to exit codes? Do cc_build and cc_run now have
> exit
> > codes?
>
> The short answer here is: no. However attention to exit codes, and
> exit codes from cc_build and cc_run are separate issues, aren't they?

Actually, I thought I might as well implement exit codes from
C<cc_build> and see if i could improve C<cc_run>. See r21257 for
details. C<cc_run> already returns the slurped text from the relevant
calls within itself, so returning an error code might not be a good
thing (maybe the sub needs to be reimplemented). C<cc_build> now
returns an exit code.

In my earlier commit (getting Configure.pl to die more gracefully when
the compiler doesn't work) explicit C<exit 1;> statements are used so
that exiting is forced and exit codes from C<_run_command> are observed.

Does that help answer your objections?

Paul


Andy Dougherty

unread,
Sep 13, 2007, 11:07:05 AM9/13/07
to Perl6 Internals

I'm afraid I can't test it today (the system is unavailable) but I can
tell by just looking that even if cc_build fails, this will ignore the
failure and just keep churning along, so you won't get the "graceful 'no
compiler' message".

I guess I don't see the point of opening a new ticket to rehash the issues
of the old, and I don't see the point of closing this ticket until it
actually addresses the issues raised. (If cc_build and cc_run do get
meaningful exit codes, inter::progs needs to be revisited anyway to
actually use those codes.) But I also don't really care enough to argue
about it either. Do whatever you think appropriate.

--
Andy Dougherty doug...@lafayette.edu

Paul Cochrane

unread,
Sep 13, 2007, 11:27:03 AM9/13/07
to Andy Dougherty, Perl6 Internals

The weird thing is that there *is* a graceful 'no compiler' message.
If cc_build fails then inter::progs exits with an appropriate error
message, and configuration stops at this point. I've tested this on
Linux, Windows and Cygwin. The only place this doesn't work is on
Solaris (for some reason C<exit 1;> just doesn't seem to want to exit
on this platform). Also, the problem on Solaris turns up in
hints::solaris, and I can't see what is being done specially there
such that things don't barf when we ask them to...

> I guess I don't see the point of opening a new ticket to rehash the issues
> of the old, and I don't see the point of closing this ticket until it
> actually addresses the issues raised.

Agreed. I'd like to get this issue solved as it is likely to help
other configuration steps which should also stop after an error has
occurred.

> (If cc_build and cc_run do get
> meaningful exit codes, inter::progs needs to be revisited anyway to
> actually use those codes.) But I also don't really care enough to argue
> about it either. Do whatever you think appropriate.

I apologise if this discussion is tiring. I'm not trying to make this hard...

Paul

Andy Dougherty

unread,
Sep 13, 2007, 2:43:22 PM9/13/07
to Paul Cochrane, Perl6 Internals
On Thu, 13 Sep 2007, Paul Cochrane wrote:

> The weird thing is that there *is* a graceful 'no compiler' message.
> If cc_build fails then inter::progs exits with an appropriate error
> message, and configuration stops at this point.

That depends on the nature of the failure in cc_build. In the example in
the ticket, I was running cc_build with perl-5.6.2, but cc_build used a
form of 3-arg open available only in 5.8.x. Checking $@ would have
turned up that error.

Stepping back a moment, the following construct is just odd:

unless ( eval { cc_run(); 1 } )

What's the purpose of the '1' there? cc_run() should be given a
meaningful return value, and then that return value should be checked.

Also, any time you run an eval, it makes sense to check whether the eval
generated any errors. The cc_run() call checks $@, but the cc_build call
does not.

Here's something like what I have in mind. Don't apply this now -- it
won't work because it incorrectly relies on the return values of cc_build
and cc_run. Those values aren't even currently documented. There's a
decision to be made there -- shall they return '0 means OK' (reflecting
that (on Unix, at least) they are implemented in terms of system()) or
shall they return 'non-zero means OK'? The latter would allow them to be
used "naturally" with tests like: if (cc_run()) { print "Ok\n";}.

diff -r -u parrot-current/config/inter/progs.pm parrot-andy/config/inter/progs.pm
--- parrot-current/config/inter/progs.pm 2007-09-12 11:15:13.000000000 -0400
+++ parrot-andy/config/inter/progs.pm 2007-09-13 13:47:13.000000000 -0400
@@ -141,13 +141,19 @@
END_C
close $out_fh;

- unless ( eval { cc_build(); 1 } ) {
+ unless ( eval { cc_build() } ) {


+ warn $@ if $@;

+ # XXX Should be more verbose here -- write out the actual
+ # test program and command line that failed so that the user
+ # can easily reproduce and fix the problem.


warn "Compilation failed with '$cc'\n";

exit 1;
}

- unless ( eval { cc_run(); 1 } ) {
+ unless ( eval { cc_run() } ) {
warn $@ if $@;
+ # XXX Should be more verbose here -- See above.
+ warn "Running the test program failed with '$cc'\n";
exit 1;
}
}

> The only place this doesn't work is on
> Solaris (for some reason C<exit 1;> just doesn't seem to want to exit
> on this platform).

I'm afraid I don't know what you mean here. exit seems to work just fine.
I think you must be referring to some different problem.

--
Andy Dougherty doug...@lafayette.edu

James E Keenan

unread,
Sep 13, 2007, 7:52:46 PM9/13/07
to perl6-i...@perl.org, Andy Dougherty
Andy Dougherty wrote:

> (If cc_build and cc_run do get
> meaningful exit codes, inter::progs needs to be revisited anyway to
> actually use those codes.)

If you do revisit config/inter/progs.pm, please bear in mind that I have
written some unit tests for that package:

[parrot] 500 $ ls t/configure/*progs* | cat
t/configure/107-inter_progs.01.t
t/configure/107-inter_progs.02.t
t/configure/107-inter_progs.03.t
t/configure/107-inter_progs.04.t


The extent to which these tests cover the code in the package can be
seen here:
http://thenceforward.net/parrot/coverage/configure-build/config-inter-progs-pm.html

So if you start refactoring, please make that a test-driven process so
that we keep the code coverage high. I'll be happy to point out any
pitfalls.

Thank you very much.
kid51

Andy Dougherty

unread,
Sep 14, 2007, 12:14:53 PM9/14/07
to James E Keenan, Perl6 Internals
On Thu, 13 Sep 2007, James E Keenan wrote:

> Andy Dougherty wrote:
>
> > (If cc_build and cc_run do get meaningful exit codes, inter::progs needs to
> > be revisited anyway to actually use those codes.)
>
> If you do revisit config/inter/progs.pm, please bear in mind that I have
> written some unit tests for that package:
>
> [parrot] 500 $ ls t/configure/*progs* | cat
> t/configure/107-inter_progs.01.t
> t/configure/107-inter_progs.02.t
> t/configure/107-inter_progs.03.t
> t/configure/107-inter_progs.04.t

To be blunt, I am more interested at the moment in whether it's trying
to do something sensible than whether or not its actual current behavior
is being tested. Testing the existing behavior assumes that the existing
behavior is what the program should actually be doing.

Trivial example: Configure.pl currently supports many incompatible ways
to say "no" (excerpts from Configure.pl --help)

--nomanicheck Don't check the MANIFEST
--cgoto=0 Don't build cgoto core - recommended when short of mem
--without-gdbm Build parrot without GDBM support
--icu-config=none Can be used to disable the autodetection feature.
It will also be disabled if you specify any other
of the following ICU options.

Rather than testing that each one is handled correctly, it would make
more sense to design and implement a single way to say "no". Then you
can test the daylights out of that.

Sorry if this sounds too grumpy. Having a testing procedure, framework,
and culture is indeed useful, and your efforts there are appreciated.
But having a good design would also be useful.

--
Andy Dougherty doug...@lafayette.edu

Allison Randal

unread,
Sep 14, 2007, 6:26:25 PM9/14/07
to Andy Dougherty, James E Keenan, Perl6 Internals
Andy Dougherty wrote:
>
> Trivial example: Configure.pl currently supports many incompatible ways
> to say "no" (excerpts from Configure.pl --help)
>
> --nomanicheck Don't check the MANIFEST
> --cgoto=0 Don't build cgoto core - recommended when short of mem
> --without-gdbm Build parrot without GDBM support
> --icu-config=none Can be used to disable the autodetection feature.
> It will also be disabled if you specify any other
> of the following ICU options.
>
> Rather than testing that each one is handled correctly, it would make
> more sense to design and implement a single way to say "no". Then you
> can test the daylights out of that.

I have agreed (in another thread), that these should be unified. So,
it's more a matter of TUITs than anything else.

> But having a good design would also be useful.

A good place to start is with a PDD-like summary of how it currently
works, if anyone is looking for a Perl 5-ish task.

Allison

James Keenan via RT

unread,
Sep 14, 2007, 11:30:34 PM9/14/07
to perl6-i...@perl.org
On Fri Sep 14 16:22:57 2007, all...@perl.org wrote:

>
> I have agreed (in another thread), that these should be unified. So,
> it's more a matter of TUITs than anything else.
>
> > But having a good design would also be useful.
>
> A good place to start is with a PDD-like summary of how it currently
> works, if anyone is looking for a Perl 5-ish task.
>

Somewhat apropos of this:

I've been discussing with Alan Rocker a research project in which we
would develop a table or spreadsheet that maps all the Configure.pl
command-line options to the configuration steps in which they are, can
be, cannot be, or should not be used. We're doing this as part of
preliminary planning for development of a file-based approach to
configuration (http://rt.perl.org/rt3/Ticket/Display.html?id=44315).
But once we have this we may be in a better position to discuss reforms
to the command-line options approach to configuration.

kid51

James Keenan via RT

unread,
Sep 14, 2007, 11:19:37 PM9/14/07
to perl6-i...@perl.org
This thread and RT ticket (41168) have been under way since Jan 03 2007
and I'm afraid that the discussion is collapsing under its own weight.
May I make an attempt at summarizing the issues? Let's proceed from the
outermost inwards.

1. Should the Parrot configuration process come to a halt if any one
configuration step fails?

Right now, Parrot::Configure::runsteps() works as a harness: If one
step fails, it goes on to the next step.

2. Even if the failure of a configuration step typically does not stop
configuration dead in its tracks, are there some configuration steps
which are more important than others (e.g., inter::progs, with respect
to its test for the presence of a C-compiler) which ought to stop
configuration cold if they fail?

3. Let's assume that we grant inter::progs more importance than other
configuration steps. How should the absence of a working C-compiler be
detected and reported?

4. There are several Parrot::Configure::Step methods such as cc_gen(),
cc_build() and cc_run(). Since these methods are essentially wrappers
around system calls to C programs, how should failures in those
underlying C programs be reported and passed through the configuration
process? (Error codes? Messages?)

5. The Configure.pl command-line options do not have a consistent
design. How should they be changed -- or should they be? (Allison has
noted that this has already been discussed in a separate thread. That
thread is http://rt.perl.org/rt3/Ticket/Display.html?id=42412, open
since Apr 10, and that's where further discussion of this issue should
take place.)

Items 1 and 2 above imply an approach to configuration considerably
different from the one we now follow -- differences which, I suspect,
would entail the revision of a Parrot Design Document. If someone
thinks we should have that discussion, that someone should open up a
separate ticket to track that discussion.

Let's skip over item 3 for a moment. Since the Parrot::Configure::Step
methods mentioned in item 4 are used in many of the configuration steps,
improving them would have wide benefits. I myself am not sure exactly
how they should be improved, but I would recommend opening up a separate
RT ticket for each of those methods as needed.

Back to item 3. We never did resolve the question of detection of a
working C-compiler. IMO, that's the question that we should continue to
discuss in RT -- and the only issue that should continue to be discussed
in this particular RT. And if we think that our current method of
detecting a C-compiler is, if not perfect, good enough for the present,
then I would recommend that Paul close the ticket.

If you want to discuss the other issues mentioned above, I would
recommend either going to the RTs already open or opening a new one.

Allison Randal

unread,
Sep 15, 2007, 2:53:16 PM9/15/07
to perl6-i...@perl.org
James Keenan via RT wrote:
>
> I've been discussing with Alan Rocker a research project in which we
> would develop a table or spreadsheet that maps all the Configure.pl
> command-line options to the configuration steps in which they are, can
> be, cannot be, or should not be used. We're doing this as part of
> preliminary planning for development of a file-based approach to
> configuration (http://rt.perl.org/rt3/Ticket/Display.html?id=44315).
> But once we have this we may be in a better position to discuss reforms
> to the command-line options approach to configuration.

Perfect. Thanks, James!

Allison

Andy Dougherty

unread,
Sep 17, 2007, 1:22:14 PM9/17/07
to Allison Randal, James E Keenan, Perl6 Internals
On Fri, 14 Sep 2007, Allison Randal wrote:

> Andy Dougherty wrote:
> >
> > Trivial example: Configure.pl currently supports many incompatible ways to
> > say "no" (excerpts from Configure.pl --help)
> >

> > Rather than testing that each one is handled correctly, it would make
> > more sense to design and implement a single way to say "no". Then you
> > can test the daylights out of that.
>
> I have agreed (in another thread), that these should be unified. So,
> it's more a matter of TUITs than anything else.

Yes, I know, and that's part of the point. That example was intended as
an obvious example of the sort of code that I don't think needs exhaustive
test coverage.

--
Andy Dougherty doug...@lafayette.edu

Andy Dougherty

unread,
Sep 17, 2007, 1:58:02 PM9/17/07
to Perl6 Internals
On Fri, 14 Sep 2007, James Keenan via RT wrote:

> This thread and RT ticket (41168) have been under way since Jan 03 2007
> and I'm afraid that the discussion is collapsing under its own weight.
> May I make an attempt at summarizing the issues? Let's proceed from the
> outermost inwards.

[skipping to the relevant issue for this ticket]

> 3. Let's assume that we grant inter::progs more importance than other
> configuration steps. How should the absence of a working C-compiler be
> detected and reported?

Configure should try to compile and run a simple program. It should check
that the program ran, produced the desired output, and returned a
'success' exit status. If all those things don't check out, Configure
should present a message that tells the user precisely what was attempted
and what went wrong. Configure should probably offer to abort at that
point.


For comparison, here's what perl5's Configure does:

If the user specifies a non-existent C compiler (e.g. with
Configure -Dcc=NOcc) the following message is generated:

Configure: NOcc: not found
You need to find a working C compiler.
Either (purchase and) install the C compiler supplied by your OS vendor,
or for a free C compiler try http://gcc.gnu.org/
I cannot continue any further, aborting.

That's not too specific, but doesn't appear to cause too much confusion
either.

A more common occurrence (based on the mails I get) is to have a compiler,
but to have it not work as Configure expects for some reason or another.
After setting all the flags and libraries, Configure performs a sanity
check. It tries to compile and run a simple program. It checks both the
return value and the printed output. (Under at least one release of the
SFIO library, sfio's configuration script caused confusion between exit()
and _exit() with the net result that the program compiled fine, ran, and
exited with a return value of 0, but didn't actually print anything.
Accordingly, perl5's Configure tests both the output and the exit status.)
If this test fails, the following information is printed: (here I passed
in a bad library with sh Configure -Dlibs=-lnosuch

Checking your choice of C compiler and flags for coherency...
I've tried to compile and run the following simple program:

#include <stdio.h>
int main() { printf("Ok\n"); return(0); }

I used the command:

cc -o try -O -I/usr/local/include -L/usr/ccs/lib -L/opt/SUNWspro/SC4.2/lib -L/usr/local/lib try.c -lnosuch
./try

and I got the following output:

ld: fatal: library -lnosuch: not found
ld: fatal: File processing errors. No output written to try
I can't compile the test program.
(The supplied flags or libraries might be incorrect.)

You have a BIG problem. Shall I abort Configure [y]
Ok. Stopping Configure.


This error message tells the user precisely what happened and gives enough
information for the user to easily reproduce (and, I hope, fix) the

Jerry Gay

unread,
Sep 17, 2007, 2:28:58 PM9/17/07
to Andy Dougherty, Perl6 Internals
i agree with everything andy has to say about the way Configure.pl
should handle a missing compiler. only one *minor* nit to pick, with
the code run to detect a working compiler:

> int main() { printf("Ok\n"); return(0); }

magic numbers are bad. use C89-friendly and much more expressive
C<EXIT_SUCCESS> in place of C<0>.
~jerry

James Keenan via RT

unread,
Oct 20, 2007, 9:17:57 AM10/20/07
to perl6-i...@perl.org
In r22303 I have committed patches which address -- and may even
resolve! -- the issues discussed in this ticket. Default behavior is
largely unchanged, i.e., if a configuration step fails, Configure.pl
proceeds to the next step. But now, at the end of configuration, you
get a printout of the steps that failed and a caution about proceeding
further.

If that's not sufficient, with the --fatal-step option you can now
designate one or more steps (comma-delimited list) as causing
configuration to halt upon step failure.

And if *that's* not sufficient, you can run Configure.pl with the
--fatal option, whereupon the failure of *any* configuration step will
cause all configuration to halt.

James Keenan via RT

unread,
Feb 24, 2008, 8:38:43 PM2/24/08
to perl6-i...@perl.org
Somewhat apropos the discussion in this old ticket, tonight I noticed
the following code in config/inter/progs.pm:


sub cc_run {
...
my $run_error;
if ( defined( $_[0] ) && length( $_[0] ) ) {
local $" = ' ';
$run_error = _run_command( "$test_exe @_", './test.out', undef,
$verbose );
}
else {
$run_error = _run_command( "$test_exe", './test.out', undef,
$verbose );
}

my $output = _slurp('./test.out');

return $output;
}

Note that nothing is ever done with $run_error. Would it be of any use
in giving a more descriptive explanation of why comfiguration might fail?

(Or, since this method is called in *many* locations, would making a
change here create more problems than it would solve?)

kid51

James Keenan via RT

unread,
Jun 8, 2008, 9:42:06 PM6/8/08
to perl6-i...@perl.org
On Sun Feb 24 17:38:36 2008, jk...@verizon.net wrote:
> Somewhat apropos the discussion in this old ticket, tonight I noticed
> the following code in config/inter/progs.pm:
>
>
> sub cc_run {

Correction: cc_run() is defined in lib/Parrot/Configure/Compiler.pm.

James Keenan via RT

unread,
Nov 24, 2008, 7:16:59 PM11/24/08
to parro...@lists.parrot.org, perl6-i...@perl.org
On Mon Nov 24 13:45:03 2008, coke wrote:

>
> I'm satisfied that the original request is resolved. There's a lot of
> discussion further down in the ticket which I /think/ can be shelved
> until whenever config is looked at down the road.
>

Agreed. I will take the ticket now and close it in a few days unless
someone registers strong objection.

kid51

0 new messages