kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #10461
Re: data in headers
On 5/23/2013 10:04 AM, Dick Hollenbeck wrote:
> 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.
Wow! How did you manage dig that out of the repo? That goes all the
way back in 2009. I had look at the diff to remember what I did. Time
flies when your having fun. :)
>
> Beautiful source code attracts people to the project.
>
> No small part of our improvement is due to Wayne's excellent, cumulative work.
>
> Dick
Thanks. I appreciate it! Hopefully I can continue to make meaningful
contributions to KiCad. I've enjoyed collaborating on the project with
you, JP, and the other developers who have helped to make KiCad what it
is today. Thank you all and keep up the good work.
Wayne
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help : https://help.launchpad.net/ListHelp
>
References