kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

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.

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.

I don't have any vision into the problem.  Seek first to understand.

After looking at the preprocessor output, only then do we begin to see what the compiler
is seeing in the code stream.  Correlating the compiler error message with the
preprocessor output will give a better idea.

I have no idea right now, not from your description, which is too myopic.

Its best to first understand the problem before trying to fix it.



KIWAY Build Symbols, Definitions and Intentions


COMPILING_DLL:

    This is a signal to import_export.h, and when present, toggles the
    interpretation of the #defines in that file. Its purpose should not be
    extended beyond this.


USE_KIWAY_DLLS:

    Comes from CMake as a user configuration variable, settable in the Cmake
    user interface. It decides if KiCad will be built with the *.kiface program
    modules.


BUILD_KIWAY_DLL:

    Comes from CMake, but at the 2nd tier, not the top tier. By 2nd tier,
    something like pcbnew/CMakeLists.txt, not /CMakeLists.txt is meant. It is
    not a user configuration variable. Instead, the 2nd tier CMakeLists.txt file
    looks at the top level USE_KIWAY_DLLS and decides how the object files under
    the 2nd tier's control will be built. If it decides it want to march in
    lockstep with USE_KIWAY_DLLS, then this local CMakeLists.txt file may pass a
    defined BUILD_KIWAY_DLL (singular) on the compiler command line to the
    pertinent set of compilation steps under its control.