On 2007-05-22, at 07:31:50 -0400, via RT wrote:
Show quoted text> Here's a few minor nits that I experienced when using "perl ppport.h"
> recently.
>
> 1. I ran "perl ppport.h --copy=new" expecting that ".new" would be
> appended to modified files' names, but instead it only appended "new".
> The POD says "--copy=suffix" and to me "suffix" suggests just the
> letters after the last "." in a filename, so I didn't expect to have to
> run "perl ppport.h --copy=.new" to get what I wanted. Perhaps a "."
> could be prepended to the value of the --copy option if that value
> doesn't already begin with a "."?
Mmmh, yes, that sounds reasonable. But what if you actually wanted
to leave the dot out in the middle? If ppport.h would automagically
add a dot, there would be no way to do this. (I don't know if there
would probably be any sort of problems on VMS if you wanted to
rename a file "foo.c" to "foo.c.new"?)
So, I really understand your point, but I think this problem is
best solved in the documentation.
And, for example, configure for gcc has options that influence the
names of the installed programs:
Program names:
--program-prefix=PREFIX prepend PREFIX to installed program names
--program-suffix=SUFFIX append SUFFIX to installed program names
These options also don't add any characters in between.
Show quoted text> 2. I ran "perl ppport.h foo-c.inc" and found that my explicitly named
> file , "foo-c.inc", got skipped unless I also specified --nofilter!
> Perhaps the --nofilter option could be implied if files are explicitly
> named rather than picked up by directory search or file glob?
Well, that would be a nice idea. Unfortunately, the shell already
does the globbing:
mhx@r2d2 $ perl -le'print for @ARGV' *
apicheck_c.PL
blib
Changes
devel
HACKERS
[...]
The filtering is done mainly to stop ppport.h from doing stupid
things to files that are not source files.
I could blindly add '.inc' as an extension that passes through
the filter, but that's not safe. However, "-c.inc" and "-xs.inc"
are commonly used. I'll add these to the list of known file
extensions. This should, at least somehow, solve your problem.
Show quoted text> 3. In several cases, "perl ppport.h --copy=.new" output a new file in
> which the only change was the addition of "#include "ppport.h"". In each
> case, that actually wasn't necessary because the source file in question
> already #included another source file which #included ppport.h itself.
> Would it be possible for the analyzer to follow #include directives to
> spot cases like this?
Uh, well, I guess it would be possible. But I have some concerns:
1. ppport.h is already too big. :-)
2. There is code in ppport.h to actually remove an
#include "ppport.h"
if it appears not to be needed. If it's not needed in your
included file, it might be dropped from there and moved to
the other file that included the first one. This would make
the logic much more complicated.
3. As ppport.h is configurable, it's not (always) a good idea
to put it into a file that's included from another file.
I guess I'll have to think about this a little more. Maybe I can
come up with a fancy solution that doesn't increase the code size
too much.
I've added this to my TODO list.
Show quoted text> Obviously these are not important issues, but it would have made things
> run a little more smoothly for me the other day if the above changes had
> been implemented.
I think issues (1) and (2) should be solved in the next release.
I've improved the documentation for --copy, and I've added
-c.inc and -xs.inc to the list of known source file extensions.
Marcus
--
economist, n:
Someone who's good with figures, but doesn't have enough
personality to become an accountant.
