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', unde
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 ste
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 in
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
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.
[skip
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 cu
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
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
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
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/confi
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 e
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
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
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 c
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,
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 l
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 ent
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 as
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 executabl
On Mon, 4 Jun 2007, James Keenan via RT wrote:
> On Fri Jun 01 09:29:18 2007, chromatic 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 f
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
On Fri Jun 01 09:29:18 2007, chromatic 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 the
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
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 gre
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 a
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 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
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 recomme
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
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,
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 ti
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 (a
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 report
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 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 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 '/?' swit
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 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
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!
# New Ticket Created by Will Coleda
# Please include the string: [perl #41168]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=41168 >
It would be nice if configure.pl gracefully handled the error condition of
"no compiler
41 matches
Mail list logo