[glideplan_swproj] Re: [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 13:08:47 +0100 (CET)
But wait. What if one library imports another?
Yes, it' only theory, but in that case there shouldn't be the same name.
T.
> ------------ Původní zpráva ------------
> Od: Tomáš Zámečník <pulcik@xxxxxxxx>
> Předmět: [glideplan_swproj] Re: [glideplan_swproj] Re: On library creating
> Datum: 05.1.2012 13:06:43
> ----------------------------------------
> Oh, I missed your answers in the middle of e-mail.
>
> When I ran cmake again the changes in the project's dependencies weren't made.
>
> One name for exports ...good idea.
> So I will use the name you mentioned ... UPDRAFT_LIB_INTERNAL
>
> 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:
> //www.freelists.org/list/glideplan_swproj
>
>
>
To visit archive or unsubscribe, follow:
//www.freelists.org/list/glideplan_swproj
Other related posts:
- » [glideplan_swproj] Re: [glideplan_swproj] Re: [glideplan_swproj] Re: On library creating - Tomáš Zámečník
