[CMake] Creating a static lib from other static libs, HOW?

Juan Sanchez Juan.Sanchez at amd.com
Sun Sep 23 15:56:07 EDT 2007


Hello Brandon,

What is the appropriate email list for doing things in cmake for a
particular architecture, like Unix?

There is a rich history in many disciplines where people need to address
a compelling need in a specific case.  Once the immediate need is
addressed, the system can be extended for the general case.

In some instances, it is impossible to abstract away the differences for
different architectures.  For example, CMAKE has particular commands
focused particularly on the way windows libraries work.

Is there a safe forum where we can discuss these issues?

Thanks,

Juan

Brandon Van Every wrote:
> On 9/22/07, Goswin von Brederlow <brederlo at informatik.uni-tuebingen.de> wrote:
>> "Brandon Van Every" <bvanevery at gmail.com> writes:
>>> If CMake considered it.  All I do is find the objects that CMake
>>> already generated, then dump them directly into a library target.
>>> CMake can swallow all kinds of stuff, *.c files, *.h files, *.o files,
>>> whatever.
>>>
>>> This is part of why I think you guys should stop messing around with
>>> non-CMake ways of doing things.  It either works and hey presto!
>> Or it just goes horribly wrong in some hidden corner with totaly
>> unpredictable effect and race conditions. That is why before
>> introducing a concept like yours you have to think out what it all
>> means.
>>
>>> you've got wonderful automagical cross-platform build stuff for no
>>> work... or it doesn't work, and you're helping CMake improve by
>>> submitting bug reports or feature requests.
> 
> Like I said the 1st time.  Help us improve CMake instead of working on
> AR-specific stuff or wringing hands about theoretical bugs that
> haven't been demonstrated yet.
> 
>> CMake will have to use AR to create the archive and it has to limit
>> the command line. If it does multiple ar calls to add more and more
>> objects it can easily overwrite exitsing entries if the wrong options
>> are used. Also commandline overflow is much more likely with long
>> pathnames. Maybe just nobody cared about it yet since it never happens
>> for normal dirs. Also with a single dir name collisions won't happen
>> while with multiple dirs they might.
> 
> So go look in the CMake sources and see if there are automated test
> cases that address these issues to your satisfaction.  If there
> aren't, write some and contribute them.  This is open source.
> 
> My method worked for my build.  I didn't make it public because I
> didn't want to deal with the full support burden of proving that it
> works everywhere for everything.  When pressured with competing, bad
> solutions, I made it public.  But you still have to go to the bug
> tracker and look up feature request #5155, so that's a barrier to
> people making casual, uninformed use of it.  I'm not currently getting
> paid to write test cases for it, so YMMV.
> 
> 
> Cheers,
> Brandon Van Every
> _______________________________________________
> CMake mailing list
> CMake at cmake.org
> http://www.cmake.org/mailman/listinfo/cmake
> 
> 





More information about the CMake mailing list