[CMake] Merge two static libraries

Marcel Loose loose at astron.nl
Tue Oct 5 07:24:37 EDT 2010


Hi Eric,

Even if you opt for the "one static library" option, you already gain in
build speed. Suppose you've modified foo.c, then CMake will only rebuild
foo.o. Of course, it will rebuild foo.o twice, once for libconsole, once
for libwindows. But that's already much better than recompiling all 50
sources twice.

Best regards,
Marcel Loose.

On Tue, 2010-10-05 at 11:17 +0200, pellegrini wrote:
> Hi Marcel,
> 
> I want a single library for respectively console and window modes 
> because I was asked to not disrupt too much the current architecture
> of the library that is created in its console and window static version. 
> That library (crysfml) is used by other softs and so we should also 
> update their installers.
> 
> Currently, the library has even no makefiles. To build it you start a 
> script (e.g. install.sh window) that will:
>     - compile the 50 files for a further use of the library for programs 
> in console mode (console.a)
>     - compile again the 50 files for a further use of the library for 
> programs in window mode (window.a)
> Everytime, you change any file in the library, you have to redo all the 
> process ... quite boring ...
> 
> That's why, I wanted to introduce a makefile, but a clever one that, 
> when using -DBUILD_WINDOW=True, would not recompile twice
> the common files between the console and window modes.
> 
> I hope that I was a little be clearer.
> 
> thanks for your help
> 
> Marcel Loose a écrit :
> > Hi Eric,
> >
> > I still don't understand why you want to have just one library. What's
> > wrong with having a common library, containing all the common software
> > and a console/window specific library?
> >
> > You could also use shared libraries (DLLs), but I guess that's out of
> > the question for you, since you've been talking about static libraries
> > only.
> >
> > Best regards,
> > Marcel Loose.
> >
> > On Tue, 2010-10-05 at 10:45 +0200, pellegrini wrote:
> >   
> >> in fact the makefile we would like to generate should be able to:
> >>
> >>     - build the console version of library (-DBUILD_WINDOW=False)
> >>     - build the console AND the window versions of the library 
> >> (-DBUILD_WINDOW=True)
> >>
> >> this is the latter case that triggered my questions.
> >>
> >> Considering that only 2 files out of 50 will have a different 
> >> compilation flag between the console and window mode, that
> >> would be a pity to duplicate the compilation of the 48 common sources 
> >> files. That's why I was looking for a way to produce:
> >>
> >>     - once the 48 objects files common to console and window building modes
> >>     - twice the 2 object files specific to the building mode:
> >>         * once in the console mode
> >>         * once in the window mode
> >>     - make a static library for the console mode
> >>     - make a static library for the window mode
> >>
> >> That's why to do so, I planned to build:
> >>     - a static library for the 48 common files --> common.a
> >>     - a static library for the 2 specific files in console mode in which 
> >> I would have inserted common.a
> >>     - a static library for the 2 specific files in window mode in which 
> >> I would have inserted common.a
> >>
> >> but failed to perform the insertion step ...
> >>
> >> Marcel Loose a écrit :
> >>     
> >>>>>> On 5-10-2010 at 10:10, in message <4CAADD79.7000801 at ill.fr>,
> >>>>>>         
> >>>>>>             
> >>> pellegrini
> >>> <pellegrini at ill.fr> wrote: 
> >>>   
> >>>       
> >>>> Hello everybody,
> >>>>
> >>>> I have a library that can be built for a use in different modes 
> >>>> (console, window). It is made of two sets of files. The first one is
> >>>>     
> >>>>         
> >>>   
> >>>       
> >>>> common to
> >>>>  the console/window building modes while the second set has to be be
> >>>>     
> >>>>         
> >>>   
> >>>       
> >>>> built with a slightly different compiler flags depending on the
> >>>>     
> >>>>         
> >>> selected
> >>>   
> >>>       
> >>>> building mode.
> >>>>
> >>>> After many discussions here, I was advised to build a static library 
> >>>>     
> >>>>         
> >>>   
> >>>       
> >>>> for the the files common to console and window building modes
> >>>> (e.g. common.a) and to build a second static library for the files 
> >>>> depending on the building mode (e.g. console.a and window.a) linking
> >>>>     
> >>>>         
> >>> the
> >>>   
> >>>       
> >>>> latter to the first one. I did it and ... it worked ! But what I
> >>>>     
> >>>>         
> >>> would 
> >>>   
> >>>       
> >>>> like is a little bit different. I would like my console.a (or
> >>>>     
> >>>>         
> >>> window.a) 
> >>>   
> >>>       
> >>>> library to
> >>>> contain the object files of the common.a library. Indeed something
> >>>>     
> >>>>         
> >>> like 
> >>>   
> >>>       
> >>>> 'ar cr console.a library.a'.
> >>>>
> >>>> Would you have any idea ?
> >>>>
> >>>> thank you
> >>>>
> >>>> Eric
> >>>>     
> >>>>         
> >>> Hi Eric,
> >>>
> >>> My first question is: why do you want to join these two libraries. I
> >>> understand from your mail that people suggested you to create two
> >>> separate libraries. Now you want to join them again.
> >>>
> >>> To answer your question: you can't join two static libraries, not in a
> >>> portable way. You should specify a complete list of sources in your
> >>> CMakeLists.txt file for each of the two libraries. Something like:
> >>>
> >>> SET(LIB_SOURCES common.c)
> >>> IF(BUILD_CONSOLE)
> >>>   LIST(APPEND LIB_SOURCES  console.c)
> >>>   ADD_LIBRARY(console ${LIB_SOURCES})
> >>> ELSEIF(BUILD_WINDOW)
> >>>   LIST(APPEND LIB_SOURCES window.c)
> >>>   ADD_LIBRARY(window ${LIB_SOURCES})
> >>> ENDIF(BUILD_CONSOLE)
> >>>
> >>> The downside to this solution is that you have duplicates of the object
> >>> files that are part of common, but that's the price you'll have to pay
> >>> if you want to have just one static library.
> >>>
> >>> HTH,
> >>> Marcel Loose.
> >>>   
> >>>       
> >>     
> >
> >
> >   
> 
> 




More information about the CMake mailing list