kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 02/16/2014 11:33 AM, jp charras wrote:
> Le 16/02/2014 15:29, Dick Hollenbeck a écrit :
>> On 02/16/2014 06:02 AM, jp charras wrote:
>>> Le 15/02/2014 17:35, Dick Hollenbeck a écrit :
>>>>
>>>> eeschema and bitmap2component now build in the new Kiway branch.
>>>> Other apps do not yet.
>>>>
>>>
>>> <...>
>>>
>>>>
>>>> I started with bitmap2component, which was easiest, then eeschema since I would not trip
>>>> on scripting.
>>>
>>> <...>
>>>
>>>> As a development aid for running the debugger or for permanent construction, you can link
>>>> the KIFACE and other object files with the program launcher, collapsing the two link
>>>> images into one, e.g. a single *.EXE like before.  There is still a KIWAY in there, one or
>>>> more.
>>>>
>>>> For milestone A) of the modular-kicad blueprint, there is to be a program launcher.  Its
>>>> name is single_top.c.  It gets compiled multiple times and takes compiler command line
>>>> #defines.  So in effect linking single_top to a kiface implementation gives you a way to
>>>> build a program which is not discussed in milestone A).  bitmap2component uses this
>>>> technique in this revision, i.e. single_top is linked directly to KIFACE implementation,
>>>> and everything else.
>>>>
>>>> eeschema in this demo revision, is linked according to milestone A).  That means you have
>>>> a eeschema.exe and _eeschema.kiface.  I have not had a problem stepping through a debug
>>>> build of _eeschema.kiface on linux.  Just put a breakpoint at line 282 or so, the call to
>>>> KIFACE::CreateWindow().
>>>>
>>>> eeschema probably has some minor problems still, library paths may still be screwed up.
>>>
>>> <...>
>>>
>>>> Dick
>>>
>>> *Hat off, Dick.*
>>>
>>> On W7, using mingw, I compiled and run Eeschema without any problem,
>>> after a minor change in vector.h
>>> (missing #include <vector> in vector.h, and I committed this change)
>>>
>>> I have more trouble with bitmap2component,:
>>> When compiled without "COMPILING_DLL" defined, I have the error message
>>> you already know:
>>>
>>> e:/kicad-launchpad/kiway/include/kiway.h:109:29: error: function
>>> 'KIFACE* KIFACE                             _1(int*, int, EDA_PGM*)'
>>> definition is marked dllimport
>>>  #define KIFACE_GETTER       KIFACE_1
>>>                              ^
>>> e:/kicad-launchpad/kiway/bitmap2component/bitmap2cmp_gui.cpp:616:19:
>>> note: in ex                             pansion of macro 'KIFACE_GETTER'
>>>  MY_API( KIFACE* ) KIFACE_GETTER(  int* aKIFACEversion, int
>>> aKIWAYversion, EDA_P                             GM* aProcess )
>>>
>>> If I define "COMPILING_DLL" for bitmap2cmp_gui.cpp, it compiles,links
>>> and creates only bitmap2component.exe (as expected).
>>>
>>> But when I run bitmap2component.exe, it complains for missing
>>> _bitmap2component.kiface which, obviously, is not created.
>>>
>>> Is it worth I spend some time about this issue ?
>>>
>>> Thanks.
>>>
>>
>>
>> Attached is a description of the KIWAY build symbols and their meanings.
>>
>>
>> Lets assume we want to build bitmap2component as an *.exe for *now*.  But in the future,
>> *either way*, split or not split.  It's just about 15 lines in a
>> bitmap2component/CMakeLists.txt like file (program module specific) to give this
>> capability.  Its already there in eeschema/CMakeLists.txt.
>>
>> I think when we talked about this a couple of weeks ago, I asked for the preprocessor
>> output, but I don't ever recall receiving it.
> 
> Sorry, Dick.
> 
> But this issue was fixed when adding the missing "COMPILING_DLL" define
> in the CMakeList corresponding to the sample.
> 
> 
> For now, I made more tests, and I have 2 issues.
> 
> The first is mingw specific, and for me is relative to a missing
> COMPILING_DLL define in bitmap2component/CMakeList.txt
> (we have already talked about that, in the first test version of kiway)
> 
> The second is both on W7 and Linux, so I can be wrong in my understanding.
> 
>>
>> Is that because the preprocessor is the one choking, not the compiler?
>>
>> Here is how to generate the preprocessor output we want, you have go into the proper
>> directory first:
>>
>> $ cd <build-dir>
>> $ cd bitmap2component
>>
>> $ make bitmap2cmp_gui.i
>>
>> Then if that runs OK, the file we want to look at is then:
>>
>>   CMakeFiles/bitmap2component.dir/bitmap2cmp_gui.cpp.i
>>
>> found below the bitmap2component dir below the <build-dir>
>>
>> If the preprocessor is failing, that is a different problem than the compiler failing.
> 
> The preprocessor works fine. the relevant section in
> bitmap2cmp_gui.cpp.i gives:
> 
> __attribute__((dllimport)) KIFACE* KIFACE_1( int* aKIFACEversion, int
> aKIWAYversion, EDA_PGM* aProcess )
> {
>     process = (EDA_PGM*) aProcess;
>     return &kiface;
> }


Thank you.  I can see now.

Genearally, we should supply COMPILING_DLL, when:

a) including import_export.h, and

b) either compiling a DLL, or implementing a function that would otherwise be exported.
(In any case, *not importing*.  And you don't import something you are implementing.)


Here there is not actually a need to export, but for source compatibility there is no
harm.  On ELF binaries you'll see just that one symbol, because most all the rest are hidden.


I think the bug was line 18 of bitmap2component/CMakeLists.txt.  That region should look
like this:


set_source_files_properties( ../common/single_top.cpp PROPERTIES
    COMPILE_DEFINITIONS     "TOP_FRAME=0"
    )
set_source_files_properties( bitmap2cmp_gui.cpp PROPERTIES
    COMPILE_DEFINITIONS     "COMPILING_DLL"
    )


For single_top: that removes the BUILD_KIWAY_DLL and adds the COMPILING_DLL to the
compiler command line.

For bitmap2cmp_gui.cpp, that adds the COMPILING_DLL.

The import export thing was not detectable on linux since APIEXPORT and APIIMPORT are the
same.


Thanks for YOUR help.  Please try revision 4664 which is hopeful for working.

This gives us a platform for moving forward into the other programs.  The first ones are
always hardest.  :)


Dick