Add a --ccflags-append option to Configure.pl?
Hi all, To be able to configure parrot to build with icc (the intel C compiler) one currently needs a command line which looks like this: perl Configure.pl --cc=icc --link=icc --ld=icc --ccflags=" -no-gcc" --ccwarn="-wd269 -Wall -Wcheck -w2" However, the only things which need to be specified here are: (a) the cc setting (b) the icc header path the rest is set in the linux hints file. So what's the problem you ask? Well, to get icc to see its own header files, one needs to specify the icc header path in the --ccflags option. This overwrites any settings given in the hints file. It would be great to give a configure command like this instead: perl Configure.pl --cc=icc --ccflags-append= then any settings that were already in ccflags can stay, and any hints get added in without the developer having to remember what they are and then add them in at the configure command line. So, is it alright if I go and add yet another command line option to configure? Namely --ccflags-append? Paul
Re: Documenting Perl6 part 2
Just a brief note to reassure Mark--and everyone else who's interested-- that I'm not ignoring his post...I'm just fully occupied at the moment with other (paying) work. In the meantime I'm thinking very carefully about what Mark suggested. I'll reply properly as soon as I am able. Damian
Re: Add a --ccflags-append option to Configure.pl?
On Wed, 11 Jul 2007, Paul Cochrane wrote: > To be able to configure parrot to build with icc (the intel C > compiler) one currently needs a command line which looks like this: > > perl Configure.pl --cc=icc --link=icc --ld=icc > --ccflags=" -no-gcc" --ccwarn="-wd269 -Wall -Wcheck > -w2" > > However, the only things which need to be specified here are: > > (a) the cc setting > (b) the icc header path > > the rest is set in the linux hints file. > > So what's the problem you ask? Well, to get icc to see its own header > files, one needs to specify the icc header path in the --ccflags > option. This overwrites any settings given in the hints file. Then I'd say the hints file is broken. Unless it has good reason, the hints file shouldn't normally remove command-line information. In perl5 hints, the usual idiom is to add to existing ccflags, not replace them. > It > would be great to give a configure command like this instead: > > perl Configure.pl --cc=icc --ccflags-append= For consistency, I would think there should also be an -append option for every Configure variable. (Whether you wish to write it as --ccflags-append=icc_header_path or --append ccflags=icc_header_path or some other syntax is, at some level, irrelevant. What I'm saying is that instead of introducing an append syntax specific to ccflags, you should introduce a generic append syntax and then use it (if needed) for ccflags. I'm also advocating revising the hints file so the append syntax isn't needed! -- Andy Dougherty [EMAIL PROTECTED]
Re: Add a --ccflags-append option to Configure.pl?
On Jul 11, 2007, at 12:37 PM, Andy Dougherty wrote: On Wed, 11 Jul 2007, Paul Cochrane wrote: To be able to configure parrot to build with icc (the intel C compiler) one currently needs a command line which looks like this: perl Configure.pl --cc=icc --link=icc --ld=icc --ccflags=" -no-gcc" --ccwarn="-wd269 -Wall -Wcheck -w2" However, the only things which need to be specified here are: (a) the cc setting (b) the icc header path the rest is set in the linux hints file. So what's the problem you ask? Well, to get icc to see its own header files, one needs to specify the icc header path in the --ccflags option. This overwrites any settings given in the hints file. Then I'd say the hints file is broken. Unless it has good reason, the hints file shouldn't normally remove command-line information. In perl5 hints, the usual idiom is to add to existing ccflags, not replace them. It would be great to give a configure command like this instead: perl Configure.pl --cc=icc --ccflags-append= For consistency, I would think there should also be an -append option for every Configure variable. (Whether you wish to write it as --ccflags-append=icc_header_path or --append ccflags=icc_header_path or some other syntax is, at some level, irrelevant. What I'm saying is that instead of introducing an append syntax specific to ccflags, you should introduce a generic append syntax and then use it (if needed) for ccflags. I'm also advocating revising the hints file so the append syntax isn't needed! Long ago, Configure had a syntax so that you should append a flag to ccflags and cxxflags. Then it became broken, and then it was removed. -- Andy Dougherty [EMAIL PROTECTED]
[svn:parrot-pdd] r19789 - in trunk: . docs/pdds
Author: allison Date: Wed Jul 11 12:48:01 2007 New Revision: 19789 Added: trunk/docs/pdds/pdd15_object_metamodel.png (contents, props changed) trunk/docs/pdds/pdd15_object_metamodel.svg (contents, props changed) Changes in other areas also in this revision: Modified: trunk/MANIFEST Log: [pdd] Object metamodel diagrams created by George Wood at Houston hackathon. Added: trunk/docs/pdds/pdd15_object_metamodel.png == Binary file. No diff available. Added: trunk/docs/pdds/pdd15_object_metamodel.svg == --- (empty file) +++ trunk/docs/pdds/pdd15_object_metamodel.svg Wed Jul 11 12:48:01 2007 @@ -0,0 +1,51 @@ + +http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd";> +http://www.w3.org/2000/svg"; xmlns:xl="http://www.w3.org/1999/xlink"; version="1.1" viewBox="0 0 612 792" width="51pc" height="66pc">http://purl.org/dc/elements/1.1/";>2007-06-30 03:41ZMetamodelLayer 1Copyright © 2007 The Perl Foundation, Licensed under the Artistic License 2.0Allison Randal, Patrick Michaud, George Wood 2007-06-28 to 29Layer 1Classnamenamespaceinstantiated flagimmediate parentsall parentsrolesmethodvtable overloadsattribute metadataattribute lookupattribute cacheOBJECTclassattribute storeAttribute Storevalue0value1Immediate Parentsparent1parent2All Parentsparent1parent2parent3Rolesrole1role2Methodmethod name1method object1method name2method object2VTable Overloadvtable name1vtable object1vtable name2vtable object2Attribute Lookupclassnameattributeclassnameattributeindex [i.e. 0]index [i.e. 1]Attribute Cacheattribute nameindex0atribute nameindex1Attribute Metadatacharacteristicstypeclassflag1valuevaluevalueflag2attribute name1valuecharacteristicstypeclassflag1valuevaluevalueflag2attribute name2valueNamespacenameclassparententriesnamespace PMCsubroutine PMCNamespace Entries (Variant value)name1value1name2value2name3value3variable PMCParrot Class Metamodel
[svn:parrot-pdd] r19791 - in trunk: docs/pdds languages/lisp
Author: allison Date: Wed Jul 11 13:42:20 2007 New Revision: 19791 Modified: trunk/docs/pdds/pdd15_object_metamodel.svg (props changed) Changes in other areas also in this revision: Modified: trunk/languages/lisp/LICENSE (props changed) Log: Fixing svn properties.
[svn:parrot-pdd] r19792 - in trunk: compilers/imcc compilers/pirc/src config/gen/cpu/i386 docs/pdds examples/c languages/cola src src/gc src/io src/ops t/pmc t/src
Author: particle Date: Wed Jul 11 13:49:04 2007 New Revision: 19792 Modified: trunk/docs/pdds/pdd23_exceptions.pod Changes in other areas also in this revision: Modified: trunk/compilers/imcc/imclexer.c trunk/compilers/imcc/instructions.c trunk/compilers/imcc/main.c trunk/compilers/imcc/parser_util.c trunk/compilers/pirc/src/jsonout.c trunk/compilers/pirc/src/pastout.c trunk/compilers/pirc/src/pirlexer.c trunk/compilers/pirc/src/pirmain.c trunk/compilers/pirc/src/pirout.c trunk/compilers/pirc/src/pirparser.c trunk/compilers/pirc/src/pirutil.c trunk/compilers/pirc/src/pirvtable.c trunk/config/gen/cpu/i386/memcpy_mmx.c trunk/config/gen/cpu/i386/memcpy_mmx_in.c trunk/config/gen/cpu/i386/memcpy_sse.c trunk/config/gen/cpu/i386/memcpy_sse_in.c trunk/examples/c/nanoparrot.c trunk/languages/cola/gen.c trunk/languages/cola/parser.c trunk/languages/cola/semant.c trunk/languages/cola/sym.c trunk/languages/cola/type.c trunk/src/bignum.c trunk/src/exceptions.c trunk/src/gc/resources.c trunk/src/io/io_unix.c trunk/src/ops/debug.ops trunk/src/pdump.c trunk/t/pmc/bignum.t trunk/t/src/compiler.t Log: #43805: [PATCH] [CAGE] replace exit(0)/exit(1) with exit(EXIT_SUCCESS)/exit(EXIT_FAILURE) -- Courtesy of Mark Glines Modified: trunk/docs/pdds/pdd23_exceptions.pod == --- trunk/docs/pdds/pdd23_exceptions.pod(original) +++ trunk/docs/pdds/pdd23_exceptions.podWed Jul 11 13:49:04 2007 @@ -112,7 +112,7 @@ If this exception is not handled, it results in Parrot returning an error indication and the stringification of I to its embedding environment. When running standalone, this means writing the stringification of I -to standard error and executing the standard C function C. +to standard error and executing the standard C function C. =item B ]>
[perl #43805] [PATCH] [CAGE] replace exit(0)/exit(1) with exit(EXIT_SUCCESS)/exit(EXIT_FAILURE)
# New Ticket Created by Mark Glines
# Please include the string: [perl #43805]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=43805 >
C89 apparently added EXIT_SUCCESS and EXIT_FAILURE, because VMS has a
different idea of what constitutes "success". Anyway, splint warns
about it.
Builds fine on linux/x86, and test results are unchanged.
Mark
Index: src/ops/debug.ops
===
--- src/ops/debug.ops (revision 19783)
+++ src/ops/debug.ops (working copy)
@@ -102,7 +102,7 @@
PDB_run_command(interp,command);
}
/* RT#42378 this is not ok */
-exit(0);
+exit(EXIT_SUCCESS);
}
interp->pdb->cur_opcode = (opcode_t *)cur_opcode + 1;
PDB_set_break(interp,NULL);
Index: src/gc/resources.c
===
--- src/gc/resources.c (revision 19783)
+++ src/gc/resources.c (working copy)
@@ -101,7 +101,7 @@
if (!new_block) {
fprintf(stderr, "out of mem allocsize = %d\n", (int)alloc_size);
-exit(1);
+exit(EXIT_FAILURE);
}
new_block->free = alloc_size;
@@ -208,7 +208,7 @@
if (pool->top_block->free < size) {
fprintf(stderr, "out of mem\n");
-exit(1);
+exit(EXIT_FAILURE);
}
}
}
Index: src/bignum.c
===
--- src/bignum.c (revision 19783)
+++ src/bignum.c (working copy)
@@ -706,7 +706,7 @@
void
BN_exception(PINTD_ BN_EXCEPTIONS exception, const char* message) {
printf("Exception %d %s\n", exception, message);
-exit(0);
+exit(EXIT_SUCCESS);
}
/*
Index: src/pdump.c
===
--- src/pdump.c (revision 19783)
+++ src/pdump.c (working copy)
@@ -172,7 +172,7 @@
"the platform's native\n");
printf("\t binary format for better efficiency on reading "
"non native PBCs\n");
-exit(0);
+exit(EXIT_SUCCESS);
}
static struct longopt_opt_decl options[] = {
@@ -256,19 +256,19 @@
pack = (opcode_t*) mem_sys_allocate(size);
if (!pack) {
printf("out of mem\n");
-exit(1);
+exit(EXIT_FAILURE);
}
PackFile_pack(interp, interp->code->base.pf, pack);
if (strcmp(file, "-") == 0)
fp = stdout;
else if ((fp = fopen(file, "wb")) == 0) {
printf("Couldn't open %s\n", file);
-exit(1);
+exit(EXIT_FAILURE);
}
if ((1 != fwrite(pack, size, 1, fp))) {
printf("Couldn't write %s\n", file);
-exit(1);
+exit(EXIT_FAILURE);
}
fclose(fp);
mem_sys_free(pack);
Index: src/exceptions.c
===
--- src/exceptions.c (revision 19783)
+++ src/exceptions.c (working copy)
@@ -94,7 +94,7 @@
# define dumpcore() \
fprintf(stderr, "Sorry, coredump is not yet implemented " \
"for this platform.\n\n"); \
- exit(1);
+ exit(EXIT_FAILURE);
#endif
/*
Index: src/io/io_unix.c
===
--- src/io/io_unix.c (revision 19783)
+++ src/io/io_unix.c (working copy)
@@ -1031,7 +1031,7 @@
close(STDIN_FILENO);
close(fds[1]);
if (dup(fds[0]) != STDIN_FILENO) {
-exit(0);
+exit(EXIT_SUCCESS);
}
}
else {
@@ -1042,7 +1042,7 @@
if (dup(fds[0]) != STDIN_FILENO || dup(fds[1]) != STDOUT_FILENO
|| dup(fds[1]) != STDERR_FILENO)
{
-exit(0);
+exit(EXIT_SUCCESS);
}
}
/*
@@ -1059,7 +1059,7 @@
execv(cmd, argv); /* XXX use execvp ? */
/* Will never reach this unless exec fails. */
perror("execvp");
-exit(1);
+exit(EXIT_FAILURE);
}
perror("fork");
Index: compilers/imcc/instructions.c
===
--- compilers/imcc/instructions.c (revision 19783)
+++ compilers/imcc/instructions.c (working copy)
@@ -564,7 +564,7 @@
default:
fprintf(stderr, "unhandled: opsize (%d), op %s, fmt %s\n",
ins->opsize, ins->op, ins->fmt);
-exit(1);
+exit(EXIT_FAILURE);
break;
}
return len;
Index: compilers/imcc/imclexer.c
===
--- compilers/imcc/imclexer.c (revision 19783)
+++ compilers/imcc/imclexer.c (working copy)
@@ -5300,7 +5300,7 @@
if (!interp) {
fprintf(stderr, "Argh, interp not found\n");
-exit (1);
+e
[perl #43803] [PATCH] [CAGE] [TRIVIAL] fix a couple of warnings in languages/tcl
Thanks, applied as r19795
Re: [svn:parrot] r19794 - in trunk: compilers/imcc src
On Wednesday 11 July 2007 14:41:46 [EMAIL PROTECTED] wrote: > Log: > clean up defintion of str_dup for pbc_merge.c That reminds me; what does str_dup() do that strdup() doesn't do, except presumably faster and in such a way that we don't have to maintain it? -- c
[perl #43803] [PATCH] [CAGE] [TRIVIAL] fix a couple of warnings in languages/tcl
# New Ticket Created by Mark Glines
# Please include the string: [perl #43803]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=43803 >
src/binary.c:328: warning: no previous prototype for 'binary_format_number'
src/binary.c:366: warning: no previous prototype for 'binary_format_string'
Mark
=== languages/tcl/src/binary.c
==
--- languages/tcl/src/binary.c (revision 21409)
+++ languages/tcl/src/binary.c (local)
@@ -322,7 +322,7 @@
return binstr;
}
-STRING *
+static STRING *
binary_format_number(Interp *interp, char field, STRING *binstr, PMC *value,
char *format, int *formatpos, int formatlen)
{
@@ -360,7 +360,7 @@
return binstr;
}
-STRING *
+static STRING *
binary_format_string(Interp *interp, char field, STRING *binstr, PMC *value,
char *format, int *formatpos, int formatlen)
{
[perl #43655] [PATCH] Make Parrot::Configure method name more self-documenting
Applied to trunk in r19799.
Re: [svn:parrot] r19794 - in trunk: compilers/imcc src
On Jul 11, 2007, at 5:18 PM, chromatic wrote: That reminds me; what does str_dup() do that strdup() doesn't do, except presumably faster and in such a way that we don't have to maintain it? I don't know. I'm just replicating what the other standalone programs that have their own str_dup do. -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: PMC_data() harmful?
On Tuesday 10 July 2007 18:37:59 Will Coleda wrote:
> Discussion on IRC today about how we can improve the state of the GC
> system. One of the things that came up was that perhaps we shouldn't
> be poking inside PMC guts outside of src/*pmc/: instead, we should be
> using vtable access.
>
> I currently see ~500 instances where we use PMC_data() outside pmc
> code (after a build, so probably some generated code in there.)
>
> I think if we had an example of how these should be fixed, that'd
> help others contribute, so, lets pick one and dissect it.
>
> Here's a function from src/key.c :
>
> /*
>
> FUNCDOC: key_next
> Returns the next key if C is in a sequence of linked keys.
>
> */
>
> PARROT_API
> PMC *
> key_next(SHIM_INTERP, PMC *key /*NN*/)
> {
> return key->pmc_ext ? (PMC *)PMC_data(key) : NULL;
> }
>
> Is this in need of fixing? If so, how? If not, is there a better
> function to show off what needs fixing?
This isn't a great example, as the guts of hashes and keys and iterators are
all over various files instead of nicely encapsulated in .pmc files.
A better example may be PMC_cont(), strewn about ops, other PMCs, the calling
conventions, and the like. Unraveling that will be tricky.
-- c
