[glideplan_swproj] Re: [glideplan_swproj] Re: On library creating

  • From: Tomáš Zámečník <pulcik@xxxxxxxx>
  • To: glideplan_swproj@xxxxxxxxxxxxx
  • Date: Thu, 05 Jan 2012 12:58:04 +0100 (CET)

There is one reason for using separate namespace.
The library is independent on any part of updraft.
But if you think that everythinng should be, for some reasons,
in one namespace, I will change it.

T.

> ------------ Původní zpráva ------------
> Od: Kuba Marek <blue.cube@xxxxxxxxx>
> Předmět: [glideplan_swproj] Re: On library creating
> Datum: 05.1.2012 12:48:43
> ----------------------------------------
> > I added directory Updraft/src/libraries and created new CMakeLists.txt
> > The structure of the directory is same as in the case of plugins.
> > Binaries are installed to the directory with executable.
> >
> > I also created skeleton of cup library, it can serve as an example.
> >
> > Please use the same structure for the new non-plugin libraries
> > or write ideas how to changes if you are unsatisfied with this.
>
> Maybe we should put everything into Updraft namespace.
> ::Updraft::Cup::CupLoader versus ::Cup::CupLoader ...
>
> Is it necessary to separate CupLoader from CupFile?
>
> I prefer loading files from QIODevice to only specifying file name, or
> QTextStream (Ales did it this way).
> QIODevice has a lot of flexibility and it lets you do readLine.
> (QTextStream also has readLine, but it also forces some character
> encoding, because QStrings returned by it are in unicode)
>
> >
> > In rest of this message I wrote some words about libraries in general.
> >
> > When creating dynamic library you must export/import functions.
> > I attach short how-to:
> >
> > I used following code for export/import macro in my header
> > for cup files loading:
> >
> > #ifdef CUP_LIB
> > # define CUP_EXPORT Q_DECL_EXPORT
> > #else
> > # define CUP_EXPORT Q_DECL_IMPORT
> > #endif
> >
> > For proper functionallity it's necessary to add preprocessor definiton
> > to the library project.
> > Do this with CMake.
> > For my library I added following line to the cup/CMakeLists.txt:
> >
> > ADD_DEFINITIONS(-DCUP_LIB)
>
> I think it's better to use some define that doesn't contain name of the
> library (UPDRAFT_LIB_INTERNAL ?), because otherwise we won't be able to
> just copy the CMakeLists.txt.
>
> >
> > I noticed that there is already defined cup_EXPORTS value.
> > I googled it and found out that it is automatically added by cmake
> > when creating dll. But there was written that it is done on Windows.
> > If it works automatically also on Mac and Linux, ADD_DEFINITIONS
> > can be omitted.
> >
> > If you want to link a library to some project, you must add
> > TARGET_LINK_LIBRARIES command to the project's CMakeList.txt file.
> > This command ensures the right build order and specify to import the
> > lib. (There is probably some cmake code for Qt. If so, only add name
> > of the desired library to the list in command.)
> > Example...I linked cup library to the task_decl project with this
> > line:
> >
> > TARGET_LINK_LIBRARIES(${PLUGIN_NAME} ${QT_LIBRARIES} cup)
> >
> > May be you'll need to delete cache (build directory) to apply changes
> > in the project.
>
> Rerunning cmake should be enough, shouldn't it?
>
> >
> >
> > ---Some words about import/export macro
> >
> > All the magic of the export/import macro is that
> > when the header is included in other project than the library
> > (typically executable project), there is not specified the CUP_LIB
> > value so the import macro is used.
> >
> > As far as I know on the Windows happens this:
> >
> > When creating dll Visual Studio creates .dll file and also .lib file
> > which serves as an import library. (When creating static lib, VS
> > creates only .lib file which serves as the static library ...seems
> > that .lib file can have two different meanings)
> >
> > When you use some imported functions (in project which uses the
> > library), they are searched by linker in the import library
> > (so the lib file must be available to the linker and known by it)
> > Linker also add a notice to your binary telling that the function
> > will be loaded at runtime from the appropriate dll (so the dll file
> > must be available at runtime).
> >
> > Tom
>
> I'll fix my library to fit the directory structure you created.
>
> K
>
>
>

To visit archive or unsubscribe, follow:
http://www.freelists.org/list/glideplan_swproj

Other related posts: