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,
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
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
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.
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
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
Andy Dougherty wrote:
Trivial example: Configure.pl currently supports many incompatible ways
to say no (excerpts from Configure.pl --help)
--nomanicheckDon't check the MANIFEST
--cgoto=0Don't build cgoto core - recommended when short of mem
--without-gdbm
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
On Fri Sep 14 16:22:57 2007, [EMAIL PROTECTED] 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
On 12/09/2007, Andy Dougherty [EMAIL PROTECTED] wrote:
On Wed, 12 Sep 2007, Paul Cochrane via RT wrote:
On Mon Mar 19 15:59:44 2007, [EMAIL PROTECTED] wrote:
On Monday 19 March 2007 12:22, Andy Dougherty wrote:
I found the ticket that introduced this failing behavior, so I'm
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
On Thu, 13 Sep 2007, Paul Cochrane wrote:
On 12/09/2007, Andy Dougherty [EMAIL PROTECTED] wrote:
On Wed, 12 Sep 2007, Paul Cochrane via RT wrote:
On Mon Mar 19 15:59:44 2007, [EMAIL PROTECTED] wrote:
On Monday 19 March 2007 12:22, Andy Dougherty wrote:
I found the ticket that
On 13/09/2007, Andy Dougherty [EMAIL PROTECTED] wrote:
On Thu, 13 Sep 2007, Paul Cochrane wrote:
On 12/09/2007, Andy Dougherty [EMAIL PROTECTED] wrote:
On Wed, 12 Sep 2007, Paul Cochrane via RT wrote:
On Mon Mar 19 15:59:44 2007, [EMAIL PROTECTED] wrote:
On Monday 19 March 2007
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
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
On Mon Mar 19 15:59:44 2007, [EMAIL PROTECTED] wrote:
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
On Wed Sep 12 06:00:56 2007, ptc wrote:
On Mon Mar 19 15:59:44 2007, [EMAIL PROTECTED] wrote:
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.
On Wed, 12 Sep 2007, Paul Cochrane via RT wrote:
On Mon Mar 19 15:59:44 2007, [EMAIL PROTECTED] wrote:
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
On Mon, 4 Jun 2007, James Keenan via RT wrote:
On Fri Jun 01 09:29:18 2007, chromatic !-- x -- at wgz.org wrote:
This patch is very close. Instead of handling compilation manually, I
recommend instead using cc_gen() and cc_build() from
Parrot::Configure::Step.
See config/auto/sizes.pm
It's not a good assumption that the default result of a C compilation
is named a.out. On Cygwin, e.g., it's a.exe. Some compilers
default to filename.exe or bare filename (when compiling filename.c).
I think you may have to assume that it accepts the -o option and give
the tested-for executable
I was patching along the patch and hadn't tried it out myself. When I did so
tonight in the
'reconfigure' branch, I did not get good results:
CC=/usr/bin/gcc-3.3
CX=/usr/bin/g++-3.3
/usr/local/bin/perl Configure.pl --cc=$CC --cxx=$CX --link=$CX \
--ld=$CX --without-icu --without-gmp \
On Fri Jun 01 09:29:18 2007, chromatic !-- x -- at wgz.org wrote:
This patch is very close. Instead of handling compilation manually, I
recommend instead using cc_gen() and cc_build() from
Parrot::Configure::Step.
See config/auto/sizes.pm for an example.
-- c
Can you explain why using
On Thursday 31 May 2007 18:01:55 James E Keenan wrote:
Invoking the compiler on a simple source file, then checking that the
generated code exists seems such an obvious test that there must be a
fatal flaw in it. What am I missing?
This patch grew out of Hackathon Toronto and was posted
James Keenan via RT wrote:
A participant in this weekend's hackathon in Toronto posed this question:
Invoking the compiler on a simple source file, then checking that the
generated code exists seems such an obvious test that there must be a
fatal flaw in it. What am I missing?
This patch grew
On Sun, 29 Apr 2007, James Keenan via RT wrote:
A participant in this weekend's hackathon in Toronto posed this question:
Invoking the compiler on a simple source file, then checking that the
generated code exists seems such an obvious test that there must be a
fatal flaw in it. What am I
A participant in this weekend's hackathon in Toronto posed this question:
Invoking the compiler on a simple source file, then checking that the
generated code exists seems such an obvious test that there must be a
fatal flaw in it. What am I missing?
On Mon Apr 16 16:36:56 2007, [EMAIL PROTECTED] wrote:
I ran Makefile.PL on a random windows box which hasn't had its
compiler
installed correctly yet. Rather than emitting an error message about
how it couldn't find my compiler, it apparently passed the test, and
then crashed multiple times
On 28/04/07, James Keenan via RT [EMAIL PROTECTED] wrote:
On Mon Apr 16 16:36:56 2007, [EMAIL PROTECTED] wrote:
I ran Makefile.PL on a random windows box which hasn't had its
compiler
installed correctly yet. Rather than emitting an error message about
how it couldn't find my compiler, it
On Fri Apr 27 19:44:35 2007, ptc wrote:
On 28/04/07, James Keenan via RT [EMAIL PROTECTED] wrote:
On Mon Apr 16 16:36:56 2007, [EMAIL PROTECTED] wrote:
I ran Makefile.PL on a random windows box which hasn't had its
compiler
installed correctly yet. Rather than emitting an error
And (I should have asked this earlier) in what sense was the compiler not yet
installed
correctly? Was it, e.g., a standard Win32 box with no compiler at all?
I'd installed visual studio (the free compiler suite one can get from
Microsoft) but hadn't gone through all the config options
On Fri, 27 Apr 2007 19:57:47 -0700
James Keenan via RT [EMAIL PROTECTED] wrote:
And (I should have asked this earlier) in what sense was the compiler
not yet installed correctly? Was it, e.g., a standard Win32 box with
no compiler at all?
In my case, the compiler had not yet been added to
On Tue, 20 Mar 2007, chromatic wrote:
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
On Mon, 19 Mar 2007, chromatic wrote:
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
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
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
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.
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
particle++ confirmed that this patch works successfully on windows.
Closing the ticket.
On Sat Mar 17 23:51:04 2007, [EMAIL PROTECTED] wrote:
On Wed Jan 03 07:51:56 2007, coke wrote:
It would be nice if configure.pl gracefully handled the error
condition of no compiler found.
Here's a patch for that!
Patch applied in r17614. Thanks!
On Sun Mar 18 04:05:41 2007, ptc wrote:
On Sat Mar 17 23:51:04 2007, [EMAIL PROTECTED] wrote:
On Wed Jan 03 07:51:56 2007, coke wrote:
It would be nice if configure.pl gracefully handled the error
condition of no compiler found.
Here's a patch for that!
Patch applied in
# New Ticket Created by Will Coleda
# Please include the string: [perl #41168]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=41168
It would be nice if configure.pl gracefully handled the error condition of
no
41 matches
Mail list logo
