Ticket #480 (closed patch: wontfix)

Opened 5 years ago

Last modified 5 years ago

[PATCH] Display assembly filenames when compiling, like C filenames are

Reported by: wiml Owned by: jkeenan
Priority: normal Milestone:
Component: none Version: trunk
Severity: low Keywords: asmfun
Cc: Language:
Patch status: rejected Platform:

Description (last modified by jkeenan) (diff)

A trivial tweak... On platforms with assembly helpers (eg asmfun.s on ppc) the filename isn't printed when it's compiled during make, which can be briefly confusing.

Attachments

ccflags.patch Download (319 bytes) - added by wiml 5 years ago.
treat files ending in .s as source files

Change History

Changed 5 years ago by wiml

treat files ending in .s as source files

  Changed 5 years ago by jkeenan

A somewhat tangential issue:

Until I began to test this patch tonight, I was unaware of the existence of this program. I believe it is mispositioned in our repository. As I understand it, tools/dev is the location for tools Parrot developers find useful in the course of development. tools/build, in contrast, is the location for programs invoked by make, other examples being tools/build/pmc2c.pl, tools/build/ops2c.pl, etc.

So, apart from whether we apply this patch or not, I am recommending repositioning this within the tree. I will do so within a few days if there is no serious objection.

Thank you very much.
kid51

in reply to: ↑ description ; follow-up: ↓ 3   Changed 5 years ago by jkeenan

  • status changed from new to assigned
  • description modified (diff)
  • patch set to new
  • keywords asmfun added
  • owner set to jkeenan
  • summary changed from [patch] Display assembly filenames when compiling, like C filenames are to [PATCH] Display assembly filenames when compiling, like C filenames are

Replying to wiml:

A trivial tweak... On platforms with assembly helpers (eg asmfun.s on ppc) the filename isn't printed when it's compiled during make, which can be briefly confusing.

1. On Linux/i386 -- an OS which presumably would not be affected by the application of this patch -- I got the following differences in my Makefile between before and after patching:

$ diff -w 20090319.37602.parrot.txt 20090319.37602.parrot.with_cc_flags_patch.txt 
5a6
> /usr/local/bin/perl tools/build/vtable_h.pl
345d345
< /usr/local/bin/perl -MExtUtils::Command -e cp src/jit/i386/exec_dep.h src/exec_dep.h
351d350
< /usr/local/bin/perl -MExtUtils::Command -e cp src/jit/i386/exec_dep.c src/exec_dep.c

Are these differences significant? (All tests in make test passed in each case.)

2. Here is the before-and-after diff on Darwin -- an OS which presumably would be affected by the application of the patch:

$ diff -w 20090319.37602.parrot.txt \
> 20090319.37602.parrot.with_cc_flags_patch_darwin.txt
5a6
> /usr/local/bin/perl tools/build/vtable_h.pl
342a344
> src/asmfun.s
345d346
< /usr/local/bin/perl -MExtUtils::Command -e cp src/jit/ppc/exec_dep.h src/exec_dep.h
351d351
< /usr/local/bin/perl -MExtUtils::Command -e cp src/jit/ppc/exec_dep.c src/exec_dep.c

Why is the application of this patch triggering a call to tools/build/vtable_h.pl on either OS?

On Darwin, all tests in make test passed both before and after patching. So the patch seems to accomplish its objective and do no harm. But I would like to know the reason and significance of these other differences before application.

Thank you very much.
kid51

in reply to: ↑ 2   Changed 5 years ago by wiml

Replying to jkeenan:

I got the following differences in my Makefile between before and after patching

That's quite odd. I can't replicate that on my MacOSX-ppc machine. The only differences between a configure-and-build with the patch and one without are timestamps (including one in parrot_config.c encoded in hexadecimal, but still just a timestamp). Looking at the places where configure scripts reference cc_flags.pl, I don't see any that appear to care what it outputs, but I don't really grok the parrot configure system.

  Changed 5 years ago by jkeenan

  • status changed from assigned to closed
  • resolution set to wontfix
  • patch changed from new to rejected

Two months have passed since the last post to this thread. There has been no resolution to the anomalies reported above. Since the original poster characterized the patch as 'a trivial tweak', I can't see any reason to pursue this further.

I'm marking this patch rejected, but that doesn't preclude the possibility of our accepting future patches which better address the issues.

Thank you very much.
kid51

Note: See TracTickets for help on using tickets.