kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 05/23/2013 01:37 AM, jp charras wrote:
> Le 23/05/2013 04:08, Dick Hollenbeck a écrit :
>> On 05/22/2013 07:36 PM, Lorenzo Marcantonio wrote:
>>> On Wed, May 22, 2013 at 03:05:29PM -0500, Dick Hollenbeck wrote:
>>>> The more common practice is to use extern declarations in the header, and define the data
>>>> in a *.cpp file.
>>>>
>>>>
>>>> Why are you doing this?
>>>
>>> *If* it's only used there, I think he simply wanted to put aside a big
>>> definition block away from code. If these are a lot of definitions,
>>> having to declare a lot of them *and* define them is almost a code
>>> duplication.
>>>
> 
> Currently this is a work in progress.
> these files are submit to change, and my main concern was to know what 
> is specific to GOST title block, what is specific to your title block, 
> and what is common.
> 
> This work is not finished, but I have now a better knowledge of this.
> 
> The reason of this bad practice is the fact during development,
> I moved many definitions and code to new files, and removed few new 
> files when they became useless.
> 
> If I need to change CMakeLists.txt and rebuild the makefiles each time I 
> create or remove a .cpp file, the compilation time is very long.
> So currently I included these new files in an existing cpp file, just to 
> compile them quickly.
> 
> Soon, title_block_shapes_gost.h and title_block_shapes.h should be 
> renamed .cpp files because now they mainly contain code, but this was 
> not the case when I started this work (only one is compiled depending on 
> KICAD_GOST option) and worksheet_shape_builder.h moved to the include 
> folder.
> 


The end result was my concern, not the evolutionary path.

Jean-Pierre, you have an excellent attitude.  We are extremely lucky to receive your
contributions.

Sorry to have put you on the spot in the public forum, but it did not start out that way.
 I was forced to increase my amplitude faster than I originally intended in order to
maintain an effective signal to noise ratio at posting number 4.

No one will ever know how I found Wayne's exemplary commit in revision 1565, especially
among so many that he has made.

Beautiful source code attracts people to the project.

No small part of our improvement is due to Wayne's excellent, cumulative work.

Dick