Andrew, can you go ahead and commit those changes into contrib? I think
in a subdirectory would be best so that you can include the README.
Make sure the permissions are set correctly. Applying them as a patch
kept mucking them up.
header-tools or somesuch should be a fine directory name
On 11/03/2015 01:06 AM, Jeff Law wrote:
On 10/14/2015 09:14 AM, Andrew MacLeod wrote:
Here's the latest version of the tools for a sub directory in contrib.
I've handled all the feedback, except I have not fully commented the
python code in the tools, nor followed any particular coding
On 11/03/2015 09:00 AM, Jeff Law wrote:
yeah, the reducer still needs some tweaks to be generally runnable I
think. IN particular, how to deal with externally supplied macros it
cant really see. Im still thinking about that one.
Well, the solution is obvious, we continue the move away from
On 11/03/2015 06:24 AM, Andrew MacLeod wrote:
Do you have any sense of whether or not coverage of the tools has
improved over short time since we started squashing out conditional
compilation? I was running the header file reordering bits on the
trunk and was a bit surprised of how many things
On 10/14/2015 09:14 AM, Andrew MacLeod wrote:
Here's the latest version of the tools for a sub directory in contrib.
I've handled all the feedback, except I have not fully commented the
python code in the tools, nor followed any particular coding
convention... Documentation has been handled,
Here's the latest version of the tools for a sub directory in contrib.
I've handled all the feedback, except I have not fully commented the
python code in the tools, nor followed any particular coding
convention... Documentation has been handled, and I've added some
additional comments to
On Tue, 2015-10-06 at 14:02 +0200, Bernd Schmidt wrote:
[...]
> > No commenting on the quality of python code... :-) I was
> > learning python on the fly.Im sure some things are QUITE awful.,
[...]
> > + def ii_base (iinfo):
> > + return iinfo[0]
> > +
> > + def ii_path (iinfo):
> > +
I went through and addressed the comments.. Just for info, a few replies:
+ # various front ends have to set GCC_DIAG_STYLE before
including it
+ # for each file, we'll tailor where it belongs by looking at
the dup
+ # list and seeing which file is included, and position it
On 10/06/2015 04:04 PM, Andrew MacLeod wrote:
I primarily submitted it early because you wanted to look at the tools
before the code patch, which is the one I care about since the longer it
goes, the more effort it is to update the patch to mainline.
The problem is that the generated patch is
On 10/06/2015 10:56 AM, Bernd Schmidt wrote:
On 10/06/2015 04:04 PM, Andrew MacLeod wrote:
I primarily submitted it early because you wanted to look at the tools
before the code patch, which is the one I care about since the longer it
goes, the more effort it is to update the patch to
On 10/06/2015 08:02 AM, Bernd Schmidt wrote:
This sounds like the intention is to move recognized core files (I
assume these are the ones in the "order" array in the tool) to the
start, and leaving everything alone? I was a bit confused about this
at first; I see for example "timevar.h"
On 10/06/2015 09:19 PM, Andrew MacLeod wrote:
I dont get your fear. I could have created that patch by hand, it would
just take a long time, and would likely be less complete, but just as
large.
I'm not changing functionality. ALL the tool is doing is removing
header files which aren't
On 10/06/2015 02:37 PM, Bernd Schmidt wrote:
On 10/06/2015 09:19 PM, Andrew MacLeod wrote:
I dont get your fear. I could have created that patch by hand, it would
just take a long time, and would likely be less complete, but just as
large.
I'm not changing functionality. ALL the tool is
On 10/06/2015 08:04 AM, Andrew MacLeod wrote:
No commenting on the quality of python code... :-) I was
learning python on the fly.Im sure some things are QUITE awful.,
Yeah, the general impression is of fairly ad-hoc code. Not sure how
much can be done about this.
they were never intended
On 10/06/2015 04:37 PM, Bernd Schmidt wrote:
On 10/06/2015 09:19 PM, Andrew MacLeod wrote:
I dont get your fear. I could have created that patch by hand, it would
just take a long time, and would likely be less complete, but just as
large.
I'm not changing functionality. ALL the tool is
On 10/05/2015 11:18 PM, Andrew MacLeod wrote:
Here's the patch to add all the tools to contrib/headers.
Small patches should not be sent in compressed form, it makes reading
and quoting them harder. This message is only intended to contain the
patch in plain text so that I can quote it in
On 10/06/2015 08:02 AM, Bernd Schmidt wrote:
There are 9 tools I used over the run of the project. They were
developed in various stages and iterations, but I tried to at least
have
some common interface things, and I tried some cleaning up and
documentation.
I'll probably have to make
There are 9 tools I used over the run of the project. They were
developed in various stages and iterations, but I tried to at least have
some common interface things, and I tried some cleaning up and
documentation.
I'll probably have to make multiple passes over this. A disclaimer
first, I
On Tue, 6 Oct 2015, Bernd Schmidt wrote:
> General comments first. Where applicable, I think we should apply the same
> coding standards to Python as we do for C/C++. That means things like function
FWIW, glibc's rule is to follow PEP 8 formatting for Python code.
Here's the patch to add all the tools to contrib/headers.
There are 9 tools I used over the run of the project. They were
developed in various stages and iterations, but I tried to at least have
some common interface things, and I tried some cleaning up and
documentation. No commenting on
20 matches
Mail list logo
