subject:"\[CMake\] newbie question"

On 23 May 2011 00:53, Hendrik Sattler  wrote:
> Am Montag, 23. Mai 2011, 01:36:14 schrieb Sanatan Rai:
>> After cmake, and make all, the libraries build as static archives, ie I get
>> liblib1.a, liblib2.a, libhelper1.a, libhelper2.a and executable myProj in
>> the appropriate locations. However, the executable myProj does not appear
>> to have linked statically to libhelper1.a and libhelper2.a. These
>> libraries contain global initialisers for certain objects: which doesn't
>> happen when I run the executable.
>
> Most likely, the linker just drops those "global initialisers" when linking
> statically.  See the linker options in "man ld" to prevent that or give the
> library an initialisation method.

   I don't understand: so why does it work at all? I guess what I
don't understand is that
I don't see symbols from helper1 and helper2 in the final executable,
when I build them
as separate libraries, but I do when I express the dependencies thus:

  add_executable(myTarget target.cpp helpers/helper1.cpp helpers/helper2.cpp)

The `global initialisation' stuff is just the following pattern:

namespace {
  helper1 *helper1Creator()
  {
return (new helper1());
  }
  const bool helper1Registered = factory::instance().registerhelper
("helper1", helper1Creator);
}

So when I put the helpers in a separate library, these lines are not
called: which
suggests that the library was not loaded in memory. On the other hand,
when I build
them with the executable, the lines are called and everything works as expected.
I am not sure what else I can tell the linker. The libraries are
static so should be linked
statically. As far as I can tell, somehow the two helper libraries are
not being linked
at all.

Sorry, but I am quite confused.

--Sanatan
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Newbie question: Static linking

2011-05-23 Thread Hendrik Sattler


Zitat von Sanatan Rai :

The `global initialisation' stuff is just the following pattern:

namespace {
  helper1 *helper1Creator()
  {
return (new helper1());
  }
  const bool helper1Registered = factory::instance().registerhelper
("helper1", helper1Creator);
}

So when I put the helpers in a separate library, these lines are not
called.


Then you don't understand the implications of static libraries, yet.
Use the following from "man ld":
 --whole-archive
   For  each  archive  mentioned  on  the  command  line   after   the
   --whole-archive option, include every object file in the archive in
   the link, rather than searching the archive for the required object
   files.  This is normally used to turn an archive file into a shared
   library, forcing every object  to  be  included  in  the  resulting
   shared library.  This option may be used more than once.

   Two  notes when using this option from gcc: First, gcc doesn't know
   about this option, so you have to use -Wl,-whole-archive.   Second,
   don't  forget  to  use  -Wl,-no-whole-archive  after  your  list of
   archives, because gcc will add its own list  of  archives  to  your
   link and you may not want this flag to affect those as well.

HS


___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Newbie question: Static linking

On 05/23/2011 10:23 AM, Hendrik Sattler wrote:
> Zitat von Sanatan Rai :
>> The `global initialisation' stuff is just the following pattern:
>>
>> namespace {
>>   helper1 *helper1Creator()
>>   {
>> return (new helper1());
>>   }
>>   const bool helper1Registered = factory::instance().registerhelper
>> ("helper1", helper1Creator);
>> }
>>
>> So when I put the helpers in a separate library, these lines are not
>> called.
> 
> Then you don't understand the implications of static libraries, yet.
> Use the following from "man ld":
>  --whole-archive
>Foreach  archive  mentioned  on  the  command  line   after  
> the
>--whole-archive option, include every object file in the archive in
>the link, rather than searching the archive for the required object
>files.  This is normally used to turn an archive file into a shared
>library, forcing every object  to  be  included  inthe 
> resulting
>shared library.  This option may be used more than once.
> 
>Twonotes when using this option from gcc: First, gcc doesn't
> know
>about this option, so you have to use -Wl,-whole-archive.   Second,
>don't  forget  to  use  -Wl,-no-whole-archive  after your 
> list of
>archives, because gcc will add its own listof  archives  to 
> your
>link and you may not want this flag to affect those as well.
> 
> HS

But this will only work when using GNU ld (or compatible). AFAIK the
linker on APPLE uses a different option, and MSVC doesn't have an
equivalent at all (you can only specify individual symbols that should
be linked forcibly).

The real solution is to ditch this whole idea of global, static
initialization objects. It's usually a very bad solution, leading to all
kinds of non-deterministic behavior. You'll be much better off with an
explicit registration scheme.

My 2c.

Michael
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Newbie question: Static linking

On 23 May 2011 10:18, Michael Wild  wrote:
> On 05/23/2011 10:23 AM, Hendrik Sattler wrote:
>> Zitat von Sanatan Rai :
>>> The `global initialisation' stuff is just the following pattern:
>>>
>>> namespace {
>>>   helper1 *helper1Creator()
>>>   {
>>>     return (new helper1());
>>>   }
>>>   const bool helper1Registered = factory::instance().registerhelper
>>>     ("helper1", helper1Creator);
>>> }
>>>
>>> So when I put the helpers in a separate library, these lines are not
>>> called.
>>
>> Then you don't understand the implications of static libraries, yet.
>> Use the following from "man ld":
>>  --whole-archive
>>        For    each  archive  mentioned  on  the  command  line   after the
>>        --whole-archive option, include every object file in the archive in
>>        the link, rather than searching the archive for the required object
>>        files.  This is normally used to turn an archive file into a shared
>>        library, forcing every object  to  be  included  in    the

Thanks Hendrik, that works! For the record, I have added the following:

 target_link_libraries(myTarget
"-Wl,-whole-archive -L./helpers -lhelper1 -Wl,-no-whole-archive"
"-Wl,-whole-archive -L./helpers -lhelper2 -Wl,-no-whole-archive")

I am not happy about having to provide the search path explicitely, but hey.

> But this will only work when using GNU ld (or compatible). AFAIK the
> linker on APPLE uses a different option, and MSVC doesn't have an
> equivalent at all (you can only specify individual symbols that should
> be linked forcibly).
>
> The real solution is to ditch this whole idea of global, static
> initialization objects. It's usually a very bad solution, leading to all
> kinds of non-deterministic behavior. You'll be much better off with an
> explicit registration scheme.
>
> My 2c.
>
> Michael

I couldn't agree more. However, there does not appear to be an alternative
way of doing this registration. Briefly, here is the problem I am
trying to solve.

  * I have a base class (say) myBase.
  * I expect other users of my library to derive objects from myBase.
  * The application `creates' the derived objects as per the pattern above,
based on which ones the user wants as per a config file.
 * So: if the user specifies an object that is not built, then the app
is going to
   throw an exception and abort.
 * The whole point of doing this is that the application is a
`framework' for the
   user `to host his derived class'.

This approach permits me to keep the application and the `framework' code
agnostic to the user's derived classes.

I'd be more than happy to find a better way of achieving the
framework's agnosticism
to the derived classes, while providing the user to derive whatever
objects he likes.

When I solved this problem on .NET I was forced to run through all the
assemblies
to find the relevant objects and then use reflection to instantiate
them. That was even
uglier.

Thanks all!

--Sanatan
-- 
Sanatan Rai
3, Admirals Court,
30, Horselydown Lane,
London, SE1 2LJ.
+44-20-7403-2479.
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Newbie question: Static linking

2011-05-23 Thread Michael Jackson

You might want to take a look at the Factory design pattern.

-
Mike Jackson www.bluequartz.net
Principal Software Engineer   mike.jack...@bluequartz.net
BlueQuartz Software   Dayton, Ohio
Sent from my mobile device.

On May 23, 2011, at 5:51, Sanatan Rai  wrote:

> On 23 May 2011 10:18, Michael Wild  wrote:
>> On 05/23/2011 10:23 AM, Hendrik Sattler wrote:
>>> Zitat von Sanatan Rai :
 The `global initialisation' stuff is just the following pattern:

 namespace {
   helper1 *helper1Creator()
   {
 return (new helper1());
   }
   const bool helper1Registered = factory::instance().registerhelper
 ("helper1", helper1Creator);
 }

 So when I put the helpers in a separate library, these lines are not
 called.
>>>
>>> Then you don't understand the implications of static libraries, yet.
>>> Use the following from "man ld":
>>>  --whole-archive
>>>Foreach  archive  mentioned  on  the  command  line   after the
>>>--whole-archive option, include every object file in the archive in
>>>the link, rather than searching the archive for the required object
>>>files.  This is normally used to turn an archive file into a shared
>>>library, forcing every object  to  be  included  inthe
> 
>
> Thanks Hendrik, that works! For the record, I have added the following:
>
> target_link_libraries(myTarget
>"-Wl,-whole-archive -L./helpers -lhelper1 -Wl,-no-whole-archive"
>"-Wl,-whole-archive -L./helpers -lhelper2 -Wl,-no-whole-archive")
>
> I am not happy about having to provide the search path explicitely, but hey.
>
>> But this will only work when using GNU ld (or compatible). AFAIK the
>> linker on APPLE uses a different option, and MSVC doesn't have an
>> equivalent at all (you can only specify individual symbols that should
>> be linked forcibly).
>>
>> The real solution is to ditch this whole idea of global, static
>> initialization objects. It's usually a very bad solution, leading to all
>> kinds of non-deterministic behavior. You'll be much better off with an
>> explicit registration scheme.
>>
>> My 2c.
>>
>> Michael
>
> I couldn't agree more. However, there does not appear to be an alternative
> way of doing this registration. Briefly, here is the problem I am
> trying to solve.
>
>  * I have a base class (say) myBase.
>  * I expect other users of my library to derive objects from myBase.
>  * The application `creates' the derived objects as per the pattern above,
>based on which ones the user wants as per a config file.
> * So: if the user specifies an object that is not built, then the app
> is going to
>   throw an exception and abort.
> * The whole point of doing this is that the application is a
> `framework' for the
>   user `to host his derived class'.
>
> This approach permits me to keep the application and the `framework' code
> agnostic to the user's derived classes.
>
> I'd be more than happy to find a better way of achieving the
> framework's agnosticism
> to the derived classes, while providing the user to derive whatever
> objects he likes.
>
> When I solved this problem on .NET I was forced to run through all the
> assemblies
> to find the relevant objects and then use reflection to instantiate
> them. That was even
> uglier.
>
> Thanks all!
>
> --Sanatan
> --
> Sanatan Rai
> 3, Admirals Court,
> 30, Horselydown Lane,
> London, SE1 2LJ.
> +44-20-7403-2479.
> ___
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at 
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at: 
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Newbie question: Static linking

On 23 May 2011 12:54, Michael Jackson  wrote:
> You might want to take a look at the Factory design pattern.
>

That's exactly what I use...

--Sanatan
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Newbie question: Static linking

On 05/23/2011 02:20 PM, Sanatan Rai wrote:
> On 23 May 2011 12:54, Michael Jackson  wrote:
>> You might want to take a look at the Factory design pattern.
>>
> 
> That's exactly what I use...
> 
> --Sanatan

Yes, but you are registering the concrete factories implicitly instead
of explicitly, which is causing you the trouble you experience.

Better have your user provide a function registering his/her classes
explicitly.

Michael
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Newbie question: Static linking

On 23 May 2011 13:38, Michael Wild  wrote:
> On 05/23/2011 02:20 PM, Sanatan Rai wrote:
>> On 23 May 2011 12:54, Michael Jackson  wrote:
>>> You might want to take a look at the Factory design pattern.
>>>
>>
>> That's exactly what I use...
>>
>> --Sanatan
>
> Yes, but you are registering the concrete factories implicitly instead
> of explicitly, which is causing you the trouble you experience.
>
> Better have your user provide a function registering his/her classes
> explicitly.

I guess this is getting to be off topic, but indeed the
anonymous namespace trick is supposed to do exactly that.

I am not trying to be difficult here---just that it is not clear to me
that the solution to this problem is that straightforward.

When all the code files are linked in one monolithic bloc, everything
works correctly. It is when one starts dividing them into individual
libraries that this problem occurs. I haven't seen a solution to this
problem either in books or via google.

--Sanatan
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Newbie question: Static linking

On 05/23/2011 03:25 PM, Sanatan Rai wrote:
> On 23 May 2011 13:38, Michael Wild  wrote:
>> On 05/23/2011 02:20 PM, Sanatan Rai wrote:
>>> On 23 May 2011 12:54, Michael Jackson  wrote:
 You might want to take a look at the Factory design pattern.

>>>
>>> That's exactly what I use...
>>>
>>> --Sanatan
>>
>> Yes, but you are registering the concrete factories implicitly instead
>> of explicitly, which is causing you the trouble you experience.
>>
>> Better have your user provide a function registering his/her classes
>> explicitly.
> 
> I guess this is getting to be off topic, but indeed the
> anonymous namespace trick is supposed to do exactly that.
> 
> I am not trying to be difficult here---just that it is not clear to me
> that the solution to this problem is that straightforward.
> 
> When all the code files are linked in one monolithic bloc, everything
> works correctly. It is when one starts dividing them into individual
> libraries that this problem occurs. I haven't seen a solution to this
> problem either in books or via google.
> 
> --Sanatan

The problem is, that when you link a static library to another binary
(be it shared library or executable) only the *required* symbols are
used, all others get discarded. Since nothing in your code actually
references those global instances in the anonymous namespace (the linker
doesn't care about that, BTW), they are ignored.

Four solutions:

1. Only do monolithic builds.
2. Use shared libraries/DLLs
3. Use --whole-archive or similar and hack your way through MSVC (I did
it once. It was ugly. Very ugly. See
https://github.com/themiwi/cppcheck/tree/227378f763d50b005b7dd2167e2cef791054a30c.
Especially lib/CMakeLists.txt and lib/generateStaticLinkFlags.cmake. I
replaced it with an explicit registration scheme now...)
4. Use an explicit registration scheme.

For sanity's sake, go with 4.

Michael
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Newbie question: Static linking

2011-05-23 Thread Michael Jackson

On May 23, 2011, at 10:11 AM, Michael Wild wrote:

> On 05/23/2011 03:25 PM, Sanatan Rai wrote:
>> On 23 May 2011 13:38, Michael Wild  wrote:
>>> On 05/23/2011 02:20 PM, Sanatan Rai wrote:
 On 23 May 2011 12:54, Michael Jackson  wrote:
> You might want to take a look at the Factory design pattern.
> 
 
 That's exactly what I use...
 
 --Sanatan
>>> 
>>> Yes, but you are registering the concrete factories implicitly instead
>>> of explicitly, which is causing you the trouble you experience.
>>> 
>>> Better have your user provide a function registering his/her classes
>>> explicitly.
>> 
>> I guess this is getting to be off topic, but indeed the
>> anonymous namespace trick is supposed to do exactly that.
>> 
>> I am not trying to be difficult here---just that it is not clear to me
>> that the solution to this problem is that straightforward.
>> 
>> When all the code files are linked in one monolithic bloc, everything
>> works correctly. It is when one starts dividing them into individual
>> libraries that this problem occurs. I haven't seen a solution to this
>> problem either in books or via google.
>> 
>> --Sanatan
> 
> The problem is, that when you link a static library to another binary
> (be it shared library or executable) only the *required* symbols are
> used, all others get discarded. Since nothing in your code actually
> references those global instances in the anonymous namespace (the linker
> doesn't care about that, BTW), they are ignored.
> 
> Four solutions:
> 
> 1. Only do monolithic builds.
> 2. Use shared libraries/DLLs
> 3. Use --whole-archive or similar and hack your way through MSVC (I did
> it once. It was ugly. Very ugly. See
> https://github.com/themiwi/cppcheck/tree/227378f763d50b005b7dd2167e2cef791054a30c.
> Especially lib/CMakeLists.txt and lib/generateStaticLinkFlags.cmake. I
> replaced it with an explicit registration scheme now...)
> 4. Use an explicit registration scheme.
> 
> For sanity's sake, go with 4.
> 
> Michael


I use "4" in my own code and everything "just works" and I have the same type 
of setup as the original poster. I have a few of my own concrete classes and 
the user can create new ones. They just have to "register" their own new 
classes in addition to calling the "RegisterKnowFactories()" method first. This 
ensures everything links correctly and is not that much to ask your programmers 
to do. I think VTK/ITK/ParaView may also use these types of design patterns.
___
Mike Jackson  www.bluequartz.net
Principal Software Engineer   mike.jack...@bluequartz.net 
BlueQuartz Software   Dayton, Ohio


___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Newbie question: Static linking

On 05/23/2011 04:40 PM, aaron.mead...@thomsonreuters.com wrote:
>> -Original Message-
>> From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On
> Behalf Of Michael Wild
>> Sent: Monday, May 23, 2011 9:12 AM
>> To: cmake@cmake.org
>> Subject: Re: [CMake] Newbie question: Static linking
>>
>> On 05/23/2011 03:25 PM, Sanatan Rai wrote:
>>> On 23 May 2011 13:38, Michael Wild  wrote:
>>>> On 05/23/2011 02:20 PM, Sanatan Rai wrote:
>>>>> On 23 May 2011 12:54, Michael Jackson 
> wrote:
>>>>>> You might want to take a look at the Factory design pattern.
>>>>>>
>>>>>
>>>>> That's exactly what I use...
>>>>>
>>>>> --Sanatan
>>>>
>>>> Yes, but you are registering the concrete factories implicitly
> instead
>>>> of explicitly, which is causing you the trouble you experience.
>>>>
>>>> Better have your user provide a function registering his/her classes
>>>> explicitly.
>>>
>>> I guess this is getting to be off topic, but indeed the
>>> anonymous namespace trick is supposed to do exactly that.
>>>
>>> I am not trying to be difficult here---just that it is not clear to
> me
>>> that the solution to this problem is that straightforward.
>>>
>>> When all the code files are linked in one monolithic bloc, everything
>>> works correctly. It is when one starts dividing them into individual
>>> libraries that this problem occurs. I haven't seen a solution to this
>>> problem either in books or via google.
>>>
>>> --Sanatan
>>
>> The problem is, that when you link a static library to another binary
>> (be it shared library or executable) only the *required* symbols are
>> used, all others get discarded. Since nothing in your code actually
>> references those global instances in the anonymous namespace (the
> linker
>> doesn't care about that, BTW), they are ignored.
>>
>> Four solutions:
>>
>> 1. Only do monolithic builds.
>> 2. Use shared libraries/DLLs
>> 3. Use --whole-archive or similar and hack your way through MSVC (I did
>> it once. It was ugly. Very ugly. See
>> https://github.com/themiwi/cppcheck/tree/227378f763d50b005b7dd2167e2cef
> 791054a30c.
>> Especially lib/CMakeLists.txt and lib/generateStaticLinkFlags.cmake. I
>> replaced it with an explicit registration scheme now...)
>> 4. Use an explicit registration scheme.
>>
>> For sanity's sake, go with 4.
>>
>> Michael
> 
> Couldn't you do:
> 
> 5) Add references to the global instances inside something within the
> same copilational unit which you know will be imported.  (Such as a
> static reference to the global instance inside a function you know will
> be called.)

That, effectively, is an explicit registration scheme.

Michael
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Newbie question: Static linking

2011-05-23 Thread aaron . meadows

>-Original Message-
>From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On
Behalf Of Michael Wild
>Sent: Monday, May 23, 2011 9:12 AM
>To: cmake@cmake.org
>Subject: Re: [CMake] Newbie question: Static linking
>
>On 05/23/2011 03:25 PM, Sanatan Rai wrote:
>> On 23 May 2011 13:38, Michael Wild  wrote:
>>> On 05/23/2011 02:20 PM, Sanatan Rai wrote:
>>>> On 23 May 2011 12:54, Michael Jackson 
wrote:
>>>>> You might want to take a look at the Factory design pattern.
>>>>>
>>>>
>>>> That's exactly what I use...
>>>>
>>>> --Sanatan
>>>
>>> Yes, but you are registering the concrete factories implicitly
instead
>>> of explicitly, which is causing you the trouble you experience.
>>>
>>> Better have your user provide a function registering his/her classes
>>> explicitly.
>> 
>> I guess this is getting to be off topic, but indeed the
>> anonymous namespace trick is supposed to do exactly that.
>> 
>> I am not trying to be difficult here---just that it is not clear to
me
>> that the solution to this problem is that straightforward.
>> 
>> When all the code files are linked in one monolithic bloc, everything
>> works correctly. It is when one starts dividing them into individual
>> libraries that this problem occurs. I haven't seen a solution to this
>> problem either in books or via google.
>> 
>> --Sanatan
>
>The problem is, that when you link a static library to another binary
>(be it shared library or executable) only the *required* symbols are
>used, all others get discarded. Since nothing in your code actually
>references those global instances in the anonymous namespace (the
linker
>doesn't care about that, BTW), they are ignored.
>
>Four solutions:
>
>1. Only do monolithic builds.
>2. Use shared libraries/DLLs
>3. Use --whole-archive or similar and hack your way through MSVC (I did
>it once. It was ugly. Very ugly. See
>https://github.com/themiwi/cppcheck/tree/227378f763d50b005b7dd2167e2cef
791054a30c.
>Especially lib/CMakeLists.txt and lib/generateStaticLinkFlags.cmake. I
>replaced it with an explicit registration scheme now...)
>4. Use an explicit registration scheme.
>
>For sanity's sake, go with 4.
>
>Michael

Couldn't you do:

5) Add references to the global instances inside something within the
same copilational unit which you know will be imported.  (Such as a
static reference to the global instance inside a function you know will
be called.)


Aaron

This email was sent to you by Thomson Reuters, the global news and information 
company. Any views expressed in this message are those of the individual 
sender, except where the sender specifically states them to be the views of 
Thomson Reuters.
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Newbie question: Static linking

On 23 May 2011 15:11, Michael Wild  wrote:
>>> Yes, but you are registering the concrete factories implicitly instead
>>> of explicitly, which is causing you the trouble you experience.
>>>
>>> Better have your user provide a function registering his/her classes
>>> explicitly.
>>
>> I guess this is getting to be off topic, but indeed the
>> anonymous namespace trick is supposed to do exactly that.

>> libraries that this problem occurs. I haven't seen a solution to this
>> problem either in books or via google.
>>
>> --Sanatan
>
> The problem is, that when you link a static library to another binary
> (be it shared library or executable) only the *required* symbols are
> used, all others get discarded. Since nothing in your code actually
> references those global instances in the anonymous namespace (the linker
> doesn't care about that, BTW), they are ignored.
>
> Four solutions:
>
> 1. Only do monolithic builds.
> 2. Use shared libraries/DLLs
> 3. Use --whole-archive or similar and hack your way through MSVC (I did
> it once. It was ugly. Very ugly. See
> https://github.com/themiwi/cppcheck/tree/227378f763d50b005b7dd2167e2cef791054a30c.
> Especially lib/CMakeLists.txt and lib/generateStaticLinkFlags.cmake. I
> replaced it with an explicit registration scheme now...)
> 4. Use an explicit registration scheme.
>
> For sanity's sake, go with 4.

   Ok: you've lost me here. Are you saying a trick like:

   namespace {
 helper1 *createHelper1() { return (new Helper1());}
 const bool isRegistered =
factory::instance().registerHelper("helper1", createHelper1);
}
isn't explicit?

I could do the following: create a global object in the cpp, that
belongs to a type that would
do the registration. Would you regard this also as implicit?

The problem with either of these approaches is the same: if the code
lives in a separate library
that is loaded only when needed, then these registrations don't take
place. So the framework doesn't
know that the objects can be available.

Apologies for seeming obtuse but I don't follow what you mean by
`explicit registration' here.

--Sanatan
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Newbie question: Static linking

On 05/23/2011 04:51 PM, Sanatan Rai wrote:
> On 23 May 2011 15:11, Michael Wild  wrote:
 Yes, but you are registering the concrete factories implicitly instead
 of explicitly, which is causing you the trouble you experience.

 Better have your user provide a function registering his/her classes
 explicitly.
>>>
>>> I guess this is getting to be off topic, but indeed the
>>> anonymous namespace trick is supposed to do exactly that.
> 
>>> libraries that this problem occurs. I haven't seen a solution to this
>>> problem either in books or via google.
>>>
>>> --Sanatan
>>
>> The problem is, that when you link a static library to another binary
>> (be it shared library or executable) only the *required* symbols are
>> used, all others get discarded. Since nothing in your code actually
>> references those global instances in the anonymous namespace (the linker
>> doesn't care about that, BTW), they are ignored.
>>
>> Four solutions:
>>
>> 1. Only do monolithic builds.
>> 2. Use shared libraries/DLLs
>> 3. Use --whole-archive or similar and hack your way through MSVC (I did
>> it once. It was ugly. Very ugly. See
>> https://github.com/themiwi/cppcheck/tree/227378f763d50b005b7dd2167e2cef791054a30c.
>> Especially lib/CMakeLists.txt and lib/generateStaticLinkFlags.cmake. I
>> replaced it with an explicit registration scheme now...)
>> 4. Use an explicit registration scheme.
>>
>> For sanity's sake, go with 4.
> 
>Ok: you've lost me here. Are you saying a trick like:
> 
>namespace {
>  helper1 *createHelper1() { return (new Helper1());}
>  const bool isRegistered =
> factory::instance().registerHelper("helper1", createHelper1);
> }
> isn't explicit?
> 
> I could do the following: create a global object in the cpp, that
> belongs to a type that would
> do the registration. Would you regard this also as implicit?
> 
> The problem with either of these approaches is the same: if the code
> lives in a separate library
> that is loaded only when needed, then these registrations don't take
> place. So the framework doesn't
> know that the objects can be available.
> 
> Apologies for seeming obtuse but I don't follow what you mean by
> `explicit registration' here.
> 
> --Sanatan

Everything that relies on static/global initialization to register
factories is an implicit scheme. An explicit scheme is where the
dependent code (e.g. the main() function) calls a function to do the
registration.

Michael
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Newbie question: Static linking

On 23 May 2011 16:00, Michael Wild  wrote:
> Everything that relies on static/global initialization to register
> factories is an implicit scheme. An explicit scheme is where the
> dependent code (e.g. the main() function) calls a function to do the
> registration.

   Ok, got you. However, would this not imply a monolithic build? How is
main to know that an object of a type belonging to a base class of interest
exists in linked library?

   As I mentioned earlier, I did this a little more explicitly in a
.NET project in the following
manner:

  * I had a factory object, whose job it was to hold creator functions
for objects of classes
derived from a base class of interest.

 * The factory was a singleton, and had a static method that could be
called. The method loaded
   all linked assemblies, and picked out classes that were derived
from the base class.

  * Then it explicitly registered the class with the factory.

This seems to me to be a hybrid between implicit and explicit
registration. The actual mechanics
as one might imagine relied heavily on .NET reflection calls. One of
the ugliest bits of code I have
ever written.

--Sanatan
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Newbie question: Static linking

2011-05-23 Thread Michael Jackson


On May 23, 2011, at 11:09 AM, Sanatan Rai wrote:

> On 23 May 2011 16:00, Michael Wild  wrote:
>> Everything that relies on static/global initialization to register
>> factories is an implicit scheme. An explicit scheme is where the
>> dependent code (e.g. the main() function) calls a function to do the
>> registration.
> 
>   Ok, got you. However, would this not imply a monolithic build? How is
> main to know that an object of a type belonging to a base class of interest
> exists in linked library?
> 
>   As I mentioned earlier, I did this a little more explicitly in a
> .NET project in the following
> manner:
> 
>  * I had a factory object, whose job it was to hold creator functions
> for objects of classes
>derived from a base class of interest.
> 
> * The factory was a singleton, and had a static method that could be
> called. The method loaded
>   all linked assemblies, and picked out classes that were derived
> from the base class.
> 
>  * Then it explicitly registered the class with the factory.
> 
> This seems to me to be a hybrid between implicit and explicit
> registration. The actual mechanics
> as one might imagine relied heavily on .NET reflection calls. One of
> the ugliest bits of code I have
> ever written.
> 
> --Sanatan

Take a look at 
http://scm.bluequartz.net/mxa/mxadatamodel/trees/master/Code/MXA/DataImport for 
an example of how I did this in one of my older projects.

The code that ties this together is then in 
http://scm.bluequartz.net/mxa/mxadatamodel/blobs/master/Examples/DataImport/main.cpp

This should short enough for you to follow along. I am not saying mine is the 
utopian example but it does work.

Mike Jackson


___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Newbie question: Static linking

2011-05-23 Thread David Cole

On Mon, May 23, 2011 at 10:51 AM, Sanatan Rai  wrote:

> On 23 May 2011 15:11, Michael Wild  wrote:
> >>> Yes, but you are registering the concrete factories implicitly instead
> >>> of explicitly, which is causing you the trouble you experience.
> >>>
> >>> Better have your user provide a function registering his/her classes
> >>> explicitly.
> >>
> >> I guess this is getting to be off topic, but indeed the
> >> anonymous namespace trick is supposed to do exactly that.
> 
> >> libraries that this problem occurs. I haven't seen a solution to this
> >> problem either in books or via google.
> >>
> >> --Sanatan
> >
> > The problem is, that when you link a static library to another binary
> > (be it shared library or executable) only the *required* symbols are
> > used, all others get discarded. Since nothing in your code actually
> > references those global instances in the anonymous namespace (the linker
> > doesn't care about that, BTW), they are ignored.
> >
> > Four solutions:
> >
> > 1. Only do monolithic builds.
> > 2. Use shared libraries/DLLs
> > 3. Use --whole-archive or similar and hack your way through MSVC (I did
> > it once. It was ugly. Very ugly. See
> >
> https://github.com/themiwi/cppcheck/tree/227378f763d50b005b7dd2167e2cef791054a30c
> .
> > Especially lib/CMakeLists.txt and lib/generateStaticLinkFlags.cmake. I
> > replaced it with an explicit registration scheme now...)
> > 4. Use an explicit registration scheme.
> >
> > For sanity's sake, go with 4.
>
>Ok: you've lost me here. Are you saying a trick like:
>
>   namespace {
> helper1 *createHelper1() { return (new Helper1());}
> const bool isRegistered =
> factory::instance().registerHelper("helper1", createHelper1);
> }
> isn't explicit?
>

That's correct. It's not explicit. Because if nothing references the bool
variable "isRegistered" then the linker is free to (possibly) throw away
it's initialization because it's not referenced. This code may work with
some compilers; but it is not guaranteed to work.



>
> I could do the following: create a global object in the cpp, that
> belongs to a type that would
> do the registration. Would you regard this also as implicit?
>
> The problem with either of these approaches is the same: if the code
> lives in a separate library
> that is loaded only when needed, then these registrations don't take
> place. So the framework doesn't
> know that the objects can be available.
>
> Apologies for seeming obtuse but I don't follow what you mean by
> `explicit registration' here.
>

Explicit registration is having a method as mentioned earlier, something
like "RegisterKnownFactories" and then asking clients to make sure they call
that method first before calling anything that requires a factory to create
something.

HTH,
David



>
> --Sanatan
> ___
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
>
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Newbie question: Static linking

On 05/23/2011 05:09 PM, Sanatan Rai wrote:
> On 23 May 2011 16:00, Michael Wild  wrote:
>> Everything that relies on static/global initialization to register
>> factories is an implicit scheme. An explicit scheme is where the
>> dependent code (e.g. the main() function) calls a function to do the
>> registration.
> 
>Ok, got you. However, would this not imply a monolithic build? How is
> main to know that an object of a type belonging to a base class of interest
> exists in linked library?
> 
>As I mentioned earlier, I did this a little more explicitly in a
> .NET project in the following
> manner:
> 
>   * I had a factory object, whose job it was to hold creator functions
> for objects of classes
> derived from a base class of interest.
> 
>  * The factory was a singleton, and had a static method that could be
> called. The method loaded
>all linked assemblies, and picked out classes that were derived
> from the base class.
> 
>   * Then it explicitly registered the class with the factory.
> 
> This seems to me to be a hybrid between implicit and explicit
> registration. The actual mechanics
> as one might imagine relied heavily on .NET reflection calls. One of
> the ugliest bits of code I have
> ever written.
> 
> --Sanatan


If it is acceptable to have just one "hook", just require your user to
define a specific function, e.g. registerUserFactories which you then
call. Otherwise it becomes more tricky.

Michael
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Newbie question: Static linking

2011-05-23 Thread Michael Hertling

On 05/23/2011 05:09 PM, Sanatan Rai wrote:
> On 23 May 2011 16:00, Michael Wild  wrote:
>> Everything that relies on static/global initialization to register
>> factories is an implicit scheme. An explicit scheme is where the
>> dependent code (e.g. the main() function) calls a function to do the
>> registration.
> 
>Ok, got you. However, would this not imply a monolithic build? How is
> main to know that an object of a type belonging to a base class of interest
> exists in linked library?

In order to further clarify things, look at the following project:

# CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(GLOBALS CXX)
SET(CMAKE_VERBOSE_MAKEFILE ON)
ADD_LIBRARY(helper STATIC helper.cxx)
ADD_EXECUTABLE(main main.cxx)
TARGET_LINK_LIBRARIES(main helper)

// main.cxx:
int main(void){return 0;}

// helper.cxx:
#include 

class helper {};

namespace {

  bool registerhelper(const char *ident, helper *(*creator)())
  {
std::cout << ident << "=" << (void *)creator << std::endl;
  }

  helper *helperCreator()
  {
return (new helper());
  }
  const bool helperRegistered = registerhelper("helper", helperCreator);
}

If I'm not mistaken, this is roughly what you do in your project.

Although the main target is linked against libhelper.a, the object file
helper.cxx.o is dropped because none of its entities is referred to by
main.cxx, or in other words: Which reason the linker should have to
include helper.cxx.o in the final binary? To make helper.cxx.o be
included, a single reference from main.cxx usually suffices:

// helper.cxx:
#include 

int h;  // <-- For external reference.

class helper {};

namespace {

  bool registerhelper(const char *ident, helper *(*creator)())
  {
std::cout << ident << "=" << (void *)creator << std::endl;
  }

  helper *helperCreator()
  {
return (new helper());
  }
  const bool helperRegistered = registerhelper("helper", helperCreator);
}

// main.cxx:
extern int h;
int h0 = h;
int main(void){return 0;}

Now, the entities from helper.cxx.o are included in the final binary,
i.e. you'll see the "ident=..." message. Of course, the same happens
when you include helper.cxx.o immediately in the main executable by
mentioning helper.cxx among main's source files, i.e. a monolithic
build. However, be aware that advanced linkers and, in particular,
optimising compiler back-ends may feel free to remove entities that
seem to be unnecessary for the program to run, as David has remarked
in the meantime.

Michael's advice to explicitly register your factory classes means that
there will be an external reference to the concerned object files, so
they'll be included and the registration will be done via the boolean
constants' initialisation, and that's what I'd advise, too. ATM, you
try to have some actions performed in your program without referring
to these actions by any means, and this simply does not work.

Besides, when using --[no-]whole-archive in order to force the linker
to include all of a static library's object files - be aware of the
already mentioned limitations and the fact that you will get *all*
object files, not just the ones you need - you might intersperse
these flags immediately in TARGET_LINK_LIBRARIES() without -L/-l:

target_link_libraries(myTarget
-Wl,--whole-archive helper1 helper2 -Wl,--no-whole-archive)

>As I mentioned earlier, I did this a little more explicitly in a
> .NET project in the following
> manner:
> 
>   * I had a factory object, whose job it was to hold creator functions
> for objects of classes
> derived from a base class of interest.
> 
>  * The factory was a singleton, and had a static method that could be
> called. The method loaded
>all linked assemblies, and picked out classes that were derived
> from the base class.
> 
>   * Then it explicitly registered the class with the factory.
> 
> This seems to me to be a hybrid between implicit and explicit
> registration. The actual mechanics
> as one might imagine relied heavily on .NET reflection calls. One of
> the ugliest bits of code I have
> ever written.

If the object file holding the factory is placed in a static library,
and if there's no reference to any of this object file's entities from
anywhere, the above-noted approach would also fail on *nix, but you say
"...a static method that could be called.": Calling this method *is* a
reference to the factory's object file from outside, so it would be
included in the final binary, and everything works fine.

In summary, this whole issue is not related to C++ or even to CMake,
but to the manner static libraries are handled: The linker - at least
the GNU one - picks out entire object files, or drops them if they are
not referred to. This is something one must keep in mind, particularly
when dealing with global objects for initialisation purposes. BTW, also
keep in mind that the order of initialisations, i.e. constructor calls,
among global objects is unspecified; this might become important when
such g

Re: [CMake] Newbie question: Static linking

On 23 May 2011 17:46, Michael Hertling  wrote:
> On 05/23/2011 05:09 PM, Sanatan Rai wrote:
>> On 23 May 2011 16:00, Michael Wild  wrote:
>>> Everything that relies on static/global initialization to register
>>> factories is an implicit scheme. An explicit scheme is where the
>>> dependent code (e.g. the main() function) calls a function to do the
>>> registration.



>
> # CMakeLists.txt:
> CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
> PROJECT(GLOBALS CXX)
> SET(CMAKE_VERBOSE_MAKEFILE ON)
> ADD_LIBRARY(helper STATIC helper.cxx)
> ADD_EXECUTABLE(main main.cxx)



>  helper *helperCreator()
>  {
>    return (new helper());
>  }
>  const bool helperRegistered = registerhelper("helper", helperCreator);
> }
>
> If I'm not mistaken, this is roughly what you do in your project.

  Indeed.


> // helper.cxx:
> #include 
>
> int h;  // <-- For external reference.
>
> class helper {};
>
> namespace {
>
>  bool registerhelper(const char *ident, helper *(*creator)())
>  {
>    std::cout << ident << "=" << (void *)creator << std::endl;
>  }
>
>  helper *helperCreator()
>  {
>    return (new helper());
>  }
>  const bool helperRegistered = registerhelper("helper", helperCreator);
> }
>
> // main.cxx:
> extern int h;
> int h0 = h;
> int main(void){return 0;}
>
> Now, the entities from helper.cxx.o are included in the final binary,
> i.e. you'll see the "ident=..." message. Of course, the same happens
> when you include helper.cxx.o immediately in the main executable by
> mentioning helper.cxx among main's source files, i.e. a monolithic
> build. However, be aware that advanced linkers and, in particular,
> optimising compiler back-ends may feel free to remove entities that
> seem to be unnecessary for the program to run, as David has remarked
> in the meantime.

Absolutely.

> Michael's advice to explicitly register your factory classes means that
> there will be an external reference to the concerned object files, so
> they'll be included and the registration will be done via the boolean
> constants' initialisation, and that's what I'd advise, too. ATM, you
> try to have some actions performed in your program without referring
> to these actions by any means, and this simply does not work.
>
> Besides, when using --[no-]whole-archive in order to force the linker
> to include all of a static library's object files - be aware of the
> already mentioned limitations and the fact that you will get *all*
> object files, not just the ones you need - you might intersperse
> these flags immediately in TARGET_LINK_LIBRARIES() without -L/-l:
>
> target_link_libraries(myTarget
>    -Wl,--whole-archive helper1 helper2 -Wl,--no-whole-archive)
>

Yup, interspersing these flags is the approach I am taking at the moment.

>>    As I mentioned earlier, I did this a little more explicitly in a
>> .NET project in the following
>> manner:
>>
>>   * I had a factory object, whose job it was to hold creator functions
>> for objects of classes
>>     derived from a base class of interest.



> If the object file holding the factory is placed in a static library,
> and if there's no reference to any of this object file's entities from
> anywhere, the above-noted approach would also fail on *nix, but you say
> "...a static method that could be called.": Calling this method *is* a
> reference to the factory's object file from outside, so it would be
> included in the final binary, and everything works fine.

Quite.

> In summary, this whole issue is not related to C++ or even to CMake,
> but to the manner static libraries are handled: The linker - at least
> the GNU one - picks out entire object files, or drops them if they are
> not referred to. This is something one must keep in mind, particularly
> when dealing with global objects for initialisation purposes. BTW, also
> keep in mind that the order of initialisations, i.e. constructor calls,
> among global objects is unspecified; this might become important when
> such global objects refer to each other.

I do realise that it was off-topic, but people very kindly offered suggestions!
So one had to go on!

Many thanks to all for a careful and useful discussion.

Unfortunately, I am stuck with the paradigm of having to kludge loading an
entire library. For various reasons the one may not have a reference to
the hosted object in main, which must remain agnostic. Indeed, in my particular
line of business (finance), this happens to be a `standard' pattern.
Whether good or bad is a discussion that'd be too off topic...(though am happy
to continue the discussion off/on list if people are so inclined!).

--Sanatan
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Newbie question: Static linking

2011-05-23 Thread Rolf Eike Beer

Sanatan Rai wrote:

> Unfortunately, I am stuck with the paradigm of having to kludge loading an
> entire library. For various reasons the one may not have a reference to
> the hosted object in main, which must remain agnostic. Indeed, in my
> particular line of business (finance), this happens to be a `standard'
> pattern. Whether good or bad is a discussion that'd be too off
> topic...(though am happy to continue the discussion off/on list if people
> are so inclined!).

What about your application calling an initStaticLibs() function which is 
defined in an header. That header is written by CMake using FILE(WRITE ...) 
because CMake knows which libs are there and by this which init functions need 
to be called. They just have to be somehow related to the library name.

Eike

signature.asc
Description: This is a digitally signed message part.
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Newbie question: Static linking

2011-05-23 Thread Michael Hertling

On 05/23/2011 08:42 PM, Sanatan Rai wrote:
> On 23 May 2011 17:46, Michael Hertling  wrote:

>> In summary, this whole issue is not related to C++ or even to CMake,
>> but to the manner static libraries are handled: The linker - at least
>> the GNU one - picks out entire object files, or drops them if they are
>> not referred to. This is something one must keep in mind, particularly
>> when dealing with global objects for initialisation purposes. BTW, also
>> keep in mind that the order of initialisations, i.e. constructor calls,
>> among global objects is unspecified; this might become important when
>> such global objects refer to each other.
> 
> I do realise that it was off-topic, but people very kindly offered 
> suggestions!
> So one had to go on!
> 
> Many thanks to all for a careful and useful discussion.

Please don't get me wrong on this point: Far be it from me to criticise
your concern as off-topic; on a build system's mailing list, it rather
isn't, IMO. Instead, I just wanted to point out that this issue is not
immediately related to CMake or C++ but to the implications of static
libraries. Of course, we can frankly discuss it here, especially how
to address it with the means of CMake.

> Unfortunately, I am stuck with the paradigm of having to kludge loading an
> entire library. For various reasons the one may not have a reference to
> the hosted object in main, which must remain agnostic. Indeed, in my 
> particular
> line of business (finance), this happens to be a `standard' pattern.
> Whether good or bad is a discussion that'd be too off topic...(though am happy
> to continue the discussion off/on list if people are so inclined!).

In this thread, you have spoken about "loading a library", "library
loaded when needed" and "library loaded in memory", e.g., but static
libraries aren't loaded in this sense; they're examined at link time,
and that's it. May it be possible that shared libraries are what you
actually want, i.e. is there any reason why the libraries in question
must be static? Note that shared libraries don't have the limitations
of static ones; say, they are not "cherry-picked" w.r.t. object files.

If you really want to have actions performed at the program's startup
without any explicit ado, you might take a look at GCC's constructor/
destructor attributes, but be aware that this is highly dependent on
the underlying binary format and the corresponding development tools.

Regards,

Michael
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] newbie question about inline functions

2008-09-21 Thread Roy Zuo

Hello eveyone,

I am just new to cmake and have some trouble when compiling a big
project whose cpp source files are put deep inside subdirectories. 

In my CMakeLists.txt, I use AUX_SOURCE_DIRECTORY(subdir VARX) and
SET(SRC ${VAR1} ${VAR2} ...) to put all the source files in a
variable, and then use ADD_EXECUTABLE(foo main.c ${SRC}) to make the
executable. However, there are some cpp files containing only inline
functions, and when complier tries to compile them into .o files, a
lot of errors are throw out. So my question is, how to exclude those
files from the compilation? 

I know this question is naive because this is my first time working
with cmake as well as C++.

Kind regards,

Roy
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Newbie question about CMake cache

2008-10-31 Thread Joachim Ziegler

Hello list,

am I correct in the following use of the CMake cache:

Suppose that in your source code, a preprocessor macro

#if defined(USE_MEMSET)
...
#elif defined(USE_BZERO)
...
#endif

decides on whether you want to use the function memset() or bzero() to
set the first n bytes of a byte area to zero. When you invoke CMake for
the first time, you do it like this in your build tree;

$ cmake -DMEMSET:string=USE_MEMSET /path/to/source/tree

This defines a variable MEMSET in the CMake cache, with a default value
of USE_MEMSET. You can alter the value of this variable in the cache by
calling ccmake . or cmake edit_cache.

In your CMakeLists.txt, you have a section

IF(MEMSET STREQUAL USE_MEMSET)
ADD_DEFINITIONS(-DUSE_MEMSET)
ELSE(MEMSET STREQUAL USE_BZERO)
ADD_DEFINITIONS(-DUSE_BZERO)
ENDIF(MEMSET STREQUAL USE_MEMSET)

that passes on the correct macro value to the preprocessor.

Or is there an easier way to do this, to pass on macro values to the
compiler, with different values in different compiler runs?

BTW, is there a *searchable* archive of the mailing list archived at
http://www.cmake.org/pipermail/cmake/
?

Greetings,
joachim
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Newbie question: TARGET_LINK_LIBRARIES vs. ADD_DEPENDENCIES

2007-08-07 Thread Christian Convey

I've got two subprojects: A library FOO, and a program BAR.

If I have this:
ADD_EXECUTABLE(BAR main.cpp)
TARGET_LINK_LIBRARIES(BAR FOO)


Then does CMake somehow realize that it needs to build its FOO library
before trying to link the BAR program?

Or do I need to explicitly tell it to do this, using a command such as
the following?
ADD_DEPENDENCIES(FOO BAR)

Thanks,
Christian
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] newbie question - what targets are supported?

2010-05-27 Thread Doug Reiland

okay, I have ordered the book. But, in the meantime.

I am continuing to port a large library from in-house build to cmake
for evaluation.
What builtin targets are supported?

I got lex, gperf, and other kinds of stuff.

A (pseudo code) didn't work:
add_library(foo *.c *.gpref)

thanks!
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Newbie question about cmake dependency generator

2010-09-24 Thread David Aldrich

Hi

Surely been asked before, but may I ask:

Does the cmake dependency generator operate when cmake is invoked or when make 
is subsequently invoked?

Does it use a traditional method such as makedepend or is it unique to cmake?

Thanks

David
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Newbie question: generated header file howto

2008-01-10 Thread Pacesie

Hello,

In my C++ program I want to auto-generate a header ( .h ) file, which is
included in most sources. I use ADD_CUSTOM_COMMAND to generate it, but I
don't know how to neatly write the dependency to it.

I could use ADD_DEPENDENCY to add the generated header to all final targets,
but it will get messy if I have lots of targets and generated headers.

Is there a way such that generated-files are checked in each invocation of
make without explicitly referring it as a dependency to something? ie.
generated file as a final target, like ADD_CUSTOM_TARGET with the ALL option
but not phony.

Regards
Pacesie
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] newbie question about inline functions

2008-09-22 Thread Timenkov Yuri

On Mon, Sep 22, 2008 at 10:00 AM, Roy Zuo <[EMAIL PROTECTED]> wrote:

> Hello eveyone,
>
> I am just new to cmake and have some trouble when compiling a big
> project whose cpp source files are put deep inside subdirectories.
>
> In my CMakeLists.txt, I use AUX_SOURCE_DIRECTORY(subdir VARX) and
> SET(SRC ${VAR1} ${VAR2} ...) to put all the source files in a
> variable, and then use ADD_EXECUTABLE(foo main.c ${SRC}) to make the
> executable. However, there are some cpp files containing only inline
> functions, and when complier tries to compile them into .o files, a
> lot of errors are throw out. So my question is, how to exclude those
> files from the compilation?
>
> I know this question is naive because this is my first time working
> with cmake as well as C++.

There are a lot of solutions. One (possible most correct) is to keep in cpp
files only code which should be compiled. Put other code to headers. For
example, we've used ".inl" or "-inl.h" files for template code which were
included only to .cpp files (keeping prototypes in separate header).

Next, you can try using list(remove_item) function as work-around for your
problem.
For example, you know exact list of your not-to-compile files:
set(MY_INLINE_FILES file1.cpp file2.cpp)
list(remove_item SRC ${MY_INLINE_FILES})

OR, It will be better to exclude such files from compilation, keeping them
in target's sources, so CMake will put them into corresponding VS project:
set_source_files_properties(${MY_INLINE_FILES} PROPERTIES HEADER_FILE_ONLY
TRUE)
So, generated build system will not try to compile these files. We used this
approach to include all sources into Studio projects (including
linix-specific ones).
Also, you can mark them:
source_group("Inline files" ${MY_INLINE_FILES})

>
> Kind regards,
>
> Roy
> ___
> CMake mailing list
> CMake@cmake.org
> http://www.cmake.org/mailman/listinfo/cmake
>
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] newbie question about inline functions

2008-09-23 Thread Roy Zuo

Thanks a lot, and list(REMOVE_ITEM ...) works well for me.

Another stupid question, as I am really new to c++. There are some cpp
files containing only inline functions and some template class
functions. The could not be compiled correctly as well, but if I
exclude them from compilation, errors will come up in the linking
stage. How should I treat those files? 

Roy

On Mon, Sep 22, 2008 at 06:00:52PM +0400, Timenkov Yuri wrote:
> 
> Hello eveyone,
> 
> I am just new to cmake and have some trouble when compiling a big
> project whose cpp source files are put deep inside subdirectories.
> 
> In my CMakeLists.txt, I use AUX_SOURCE_DIRECTORY(subdir VARX) and
> SET(SRC ${VAR1} ${VAR2} ...) to put all the source files in a
> variable, and then use ADD_EXECUTABLE(foo main.c ${SRC}) to make the
> executable. However, there are some cpp files containing only inline
> functions, and when complier tries to compile them into .o files, a
> lot of errors are throw out. So my question is, how to exclude those
> files from the compilation?
> 
> I know this question is naive because this is my first time working
> with cmake as well as C++.
> 
> There are a lot of solutions. One (possible most correct) is to keep in cpp
> files only code which should be compiled. Put other code to headers. For
> example, we've used ".inl" or "-inl.h" files for template code which were
> included only to .cpp files (keeping prototypes in separate header).
> 
> Next, you can try using list(remove_item) function as work-around for your
> problem.
> For example, you know exact list of your not-to-compile files:
> set(MY_INLINE_FILES file1.cpp file2.cpp)
> list(remove_item SRC ${MY_INLINE_FILES})
> 
> OR, It will be better to exclude such files from compilation, keeping them in
> target's sources, so CMake will put them into corresponding VS project:
> set_source_files_properties(${MY_INLINE_FILES} PROPERTIES HEADER_FILE_ONLY
> TRUE)
> So, generated build system will not try to compile these files. We used this
> approach to include all sources into Studio projects (including linix-specific
> ones).
> Also, you can mark them:
> source_group("Inline files" ${MY_INLINE_FILES})
> 
> 
> 
> 
> Kind regards,
> 
> Roy
> ___
> CMake mailing list
> CMake@cmake.org
> http://www.cmake.org/mailman/listinfo/cmake
> 
> 

> ___
> CMake mailing list
> CMake@cmake.org
> http://www.cmake.org/mailman/listinfo/cmake
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] newbie question about inline functions

2008-09-24 Thread Timenkov Yuri

On Wed, Sep 24, 2008 at 5:11 AM, Roy Zuo <[EMAIL PROTECTED]> wrote:

> Thanks a lot, and list(REMOVE_ITEM ...) works well for me.
>
> Another stupid question, as I am really new to c++. There are some cpp
> files containing only inline functions and some template class
> functions. The could not be compiled correctly as well, but if I
> exclude them from compilation, errors will come up in the linking
> stage. How should I treat those files?

You should include these files into .cpp sources where these inlines are
used.
For example, I've used something like this:

file1.h:
template
class C
{
public:
T myfunc();
};

file1_inl.h:
template
T C::myfunc()
{
  // Implementation goes here.
}

file2.h
#include "file1.h"
// Use template class declared previously.
typedef C myC;

file2.cpp:
#include "file2.h"
#include "file1_inl.h"
// Here we can call myC::myfunc(), because its implementation is accessible
from here.

I can be wrong, because I don't know how exactly you can define template
classes and functions' implementations, but generally this should work.


>
> Roy
>
> On Mon, Sep 22, 2008 at 06:00:52PM +0400, Timenkov Yuri wrote:
> >
> > Hello eveyone,
> >
> > I am just new to cmake and have some trouble when compiling a big
> > project whose cpp source files are put deep inside subdirectories.
> >
> > In my CMakeLists.txt, I use AUX_SOURCE_DIRECTORY(subdir VARX) and
> > SET(SRC ${VAR1} ${VAR2} ...) to put all the source files in a
> > variable, and then use ADD_EXECUTABLE(foo main.c ${SRC}) to make the
> > executable. However, there are some cpp files containing only inline
> > functions, and when complier tries to compile them into .o files, a
> > lot of errors are throw out. So my question is, how to exclude those
> > files from the compilation?
> >
> > I know this question is naive because this is my first time working
> > with cmake as well as C++.
> >
> > There are a lot of solutions. One (possible most correct) is to keep in
> cpp
> > files only code which should be compiled. Put other code to headers. For
> > example, we've used ".inl" or "-inl.h" files for template code which were
> > included only to .cpp files (keeping prototypes in separate header).
> >
> > Next, you can try using list(remove_item) function as work-around for
> your
> > problem.
> > For example, you know exact list of your not-to-compile files:
> > set(MY_INLINE_FILES file1.cpp file2.cpp)
> > list(remove_item SRC ${MY_INLINE_FILES})
> >
> > OR, It will be better to exclude such files from compilation, keeping
> them in
> > target's sources, so CMake will put them into corresponding VS project:
> > set_source_files_properties(${MY_INLINE_FILES} PROPERTIES
> HEADER_FILE_ONLY
> > TRUE)
> > So, generated build system will not try to compile these files. We used
> this
> > approach to include all sources into Studio projects (including
> linix-specific
> > ones).
> > Also, you can mark them:
> > source_group("Inline files" ${MY_INLINE_FILES})
> >
> >
> >
> >
> > Kind regards,
> >
> > Roy
> > ___
> > CMake mailing list
> > CMake@cmake.org
> > http://www.cmake.org/mailman/listinfo/cmake
> >
> >
>
> > ___
> > CMake mailing list
> > CMake@cmake.org
> > http://www.cmake.org/mailman/listinfo/cmake
> ___
> CMake mailing list
> CMake@cmake.org
> http://www.cmake.org/mailman/listinfo/cmake
>
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Newbie question about CMake cache

2008-10-31 Thread Werner Smekal


Hi Joachim,


BTW, is there a *searchable* archive of the mailing list archived at
http://www.cmake.org/pipermail/cmake/
?


http://www.mail-archive.com/cmake@cmake.org/

Regards,
Werner



Greetings,
joachim
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake


--
Dr. Werner Smekal
Institut fuer Allgemeine Physik
Technische Universitaet Wien
Wiedner Hauptstr 8-10
A-1040 Wien
Austria

email: [EMAIL PROTECTED]
web: http://www.iap.tuwien.ac.at/~smekal
phone: +43-(0)1-58801-13463 (office), +43-(0)1-58801-13469 (laboratory)
fax: +43-(0)1-58801-13499

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Newbie question: TARGET_LINK_LIBRARIES vs. ADD_DEPENDENCIES

2007-08-07 Thread James Bigler


Christian Convey wrote:

I've got two subprojects: A library FOO, and a program BAR.

If I have this:
ADD_EXECUTABLE(BAR main.cpp)
TARGET_LINK_LIBRARIES(BAR FOO)


Then does CMake somehow realize that it needs to build its FOO library
before trying to link the BAR program?


Yes.  TARGET_LINK_LIBRARIES will generate a dependency for you.


Or do I need to explicitly tell it to do this, using a command such as
the following?
ADD_DEPENDENCIES(FOO BAR)

James










___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] newbie question - what targets are supported?

2010-05-27 Thread Michael Hertling

On 05/28/2010 12:14 AM, Doug Reiland wrote:
> okay, I have ordered the book. But, in the meantime.
> 
> I am continuing to port a large library from in-house build to cmake
> for evaluation.
> What builtin targets are supported?

On *nix, run CMake on a directory with an empty CMakeLists.txt, then
invoke "make help" and you'll see the targets provided a priori - or
did you rather mean "rules" instead of "targets"?

> I got lex, gperf, and other kinds of stuff.
> 
> A (pseudo code) didn't work:
> add_library(foo *.c *.gpref)

ADD_LIBRARY() et al. process source files for languages known to CMake,
primarily C and C++, but other files may be specified for dependency
tracking. To process a gperf input file, e.g., use a custom command:

ADD_CUSTOM_COMMAND(
OUTPUT xyz.c
COMMAND gperf xyz.gperf > xyz.c
DEPENDS xyz.gperf
)

The OUTPUT file can be specified in ADD_LIBRARY(foo ... xyz.c ...),
which results in the custom command being run when xyz.c is needed for
foo, but out of date. For lex and other input not intimately known to
CMake, the procedure is usually quite the same. If you have many such
files to process consider to write a function for automatization:

Regards,

Michael
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] newbie question - what targets are supported?

2010-05-27 Thread Eric Noulard

2010/5/28 Michael Hertling :
> On 05/28/2010 12:14 AM, Doug Reiland wrote:
>> okay, I have ordered the book. But, in the meantime.
>>
>> I am continuing to port a large library from in-house build to cmake
>> for evaluation.
>> What builtin targets are supported?
>
> On *nix, run CMake on a directory with an empty CMakeLists.txt, then
> invoke "make help" and you'll see the targets provided a priori - or
> did you rather mean "rules" instead of "targets"?
>
>> I got lex, gperf, and other kinds of stuff.

As a complement, many "things" are supported using custom CMake modules:

cmake --help-module-list

will give you a list of CMake modules shipped with CMake, while

cmake --help-module 

will give you more detailed information about the module.
For example:
cmake --help-module FindFLEX

may be worth reading if you are using lex.

-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] newbie question - what targets are supported?

2010-05-28 Thread Doug Reiland

Thanks. I did mean rules. The module-list is what I was after. I did piece 
together a macro for my gperf files using add_custom_command() last night 
and is working fine. But I want to make sure I am not reinventing the wheel 
here cause I am betting folks coming from make/linux world have hit the same 
things I have.


moving along slowly, it is taking longer than I thought to do this cmake 
porting test, but...


--
From: "Michael Hertling" 
Sent: Thursday, May 27, 2010 10:16 PM
To: 
Subject: Re: [CMake] newbie question - what targets are supported?


On 05/28/2010 12:14 AM, Doug Reiland wrote:

okay, I have ordered the book. But, in the meantime.

I am continuing to port a large library from in-house build to cmake
for evaluation.
What builtin targets are supported?


On *nix, run CMake on a directory with an empty CMakeLists.txt, then
invoke "make help" and you'll see the targets provided a priori - or
did you rather mean "rules" instead of "targets"?


I got lex, gperf, and other kinds of stuff.

A (pseudo code) didn't work:
add_library(foo *.c *.gpref)


ADD_LIBRARY() et al. process source files for languages known to CMake,
primarily C and C++, but other files may be specified for dependency
tracking. To process a gperf input file, e.g., use a custom command:

ADD_CUSTOM_COMMAND(
   OUTPUT xyz.c
   COMMAND gperf xyz.gperf > xyz.c
   DEPENDS xyz.gperf
)

The OUTPUT file can be specified in ADD_LIBRARY(foo ... xyz.c ...),
which results in the custom command being run when xyz.c is needed for
foo, but out of date. For lex and other input not intimately known to
CMake, the procedure is usually quite the same. If you have many such
files to process consider to write a function for automatization:

<http://www.cmake.org/pipermail/cmake/2010-May/036955.html>

Regards,

Michael
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html


Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ


Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake


___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Newbie question about cmake dependency generator

2010-09-24 Thread Alexander Neundorf

On Friday 24 September 2010, David Aldrich wrote:
> Hi
>
> Surely been asked before, but may I ask:
>
> Does the cmake dependency generator operate when cmake is invoked or when
> make is subsequently invoked?

It is invoked during the make run.

> Does it use a traditional method such as makedepend or is it unique to
> cmake?

CMake does the dependency scanning itself.

Alex
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Newbie question: generated header file howto

2008-01-10 Thread Bill Hoffman


Pacesie wrote:

Hello,

In my C++ program I want to auto-generate a header ( .h ) file, which is 
included in most sources. I use ADD_CUSTOM_COMMAND to generate it, but I 
don't know how to neatly write the dependency to it.




Add the .h file as a source file of the target that uses it.

-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Newbie question: generated header file howto

2008-01-10 Thread Pacesie

On Jan 10, 2008 11:50 PM, Bill Hoffman <[EMAIL PROTECTED]> wrote:

> Pacesie wrote:
> > Hello,
> >
> > In my C++ program I want to auto-generate a header ( .h ) file, which is
> > included in most sources. I use ADD_CUSTOM_COMMAND to generate it, but I
> > don't know how to neatly write the dependency to it.
> >
>
> Add the .h file as a source file of the target that uses it.
>
> -Bill
>

If I want to generate document files as part of the build, should I first
create an ADD_CUSTOM_TARGET then have it depends on the generated files
defined by ADD_CUSTOM_COMMAND? ( It would be nice if file generation can be
defined as a target so the extra step is not needed. )

Do the targets always run by the order that they are defined in CMakeLists
(unless there are dependency) ? So that if I want to be sure a target is run
before all others, I define it first in CMakeLists?

Thank you,
Pacesie
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Newbie question: generated header file howto

2008-01-10 Thread Alan W. Irwin


On 2008-01-11 08:05+1100 Pacesie wrote:


If I want to generate document files as part of the build, should I first
create an ADD_CUSTOM_TARGET then have it depends on the generated files
defined by ADD_CUSTOM_COMMAND? ( It would be nice if file generation can be
defined as a target so the extra step is not needed. )


You can generate the files by the appropriate custom target command, but that
will get executed for every "make" command so normally custom targets are
done without any associated command, and instead file depend on custom
commands (which are only run if the output file actually needs updating).



Do the targets always run by the order that they are defined in CMakeLists
(unless there are dependency) ? So that if I want to be sure a target is run
before all others, I define it first in CMakeLists?


If order is important between your various targets, enforce that with a
target dependency.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__

Linux-powered Science
__
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Newbie question: cmake does not have nmake generator

2009-09-09 Thread David Aldrich

Hi

I am new to cmake. I have installed cmake (using cmake-2.6.4-win32-x86.exe) on 
my Win XP platform, on which I also have Visual Studio 2005 Prof and Visual 
Studio 2008 Express installed.

I am trying to build PLplot, whose instructions tell me to run:

cmake -G "NMake Makefiles" -DCMAKE_INSTALL_PREFIX=install ..

but I get:

CMake Error: Could not create named generator
-- Check for working C compiler: gcc
-- Check for working C compiler: gcc -- broken
The C compiler "gcc" is not able to compile a simple test program.

It appears that cmake only knows about the unix generator:

C:\plplot-5.9.5\buildnmake>cmake --help
 [snip]
The following generators are available on this platform:
  Unix Makefiles  = Generates standard UNIX makefiles.

I have run Visual Studio file vcvars32.bat

How can I install the nmake and Visual Studio 8 generators please?

Best regards
David

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Newbie question: cmake does not have nmake generator

2009-09-09 Thread David Aldrich

Hi

I am new to cmake. I have installed cmake (using cmake-2.6.4-win32-x86.exe) on 
my Win XP platform, on which I also have Visual Studio 2005 Prof and Visual 
Studio 2008 Express installed.

I am trying to build PLplot, whose instructions tell me to run:

cmake -G "NMake Makefiles" -DCMAKE_INSTALL_PREFIX=install ..

but I get:

CMake Error: Could not create named generator
-- Check for working C compiler: gcc
-- Check for working C compiler: gcc -- broken
The C compiler "gcc" is not able to compile a simple test program.

It appears that cmake only knows about the unix generator:

C:\plplot-5.9.5\buildnmake>cmake --help
 [snip]
The following generators are available on this platform:
  Unix Makefiles  = Generates standard UNIX makefiles.

I have run Visual Studio file vcvars32.bat

How can I install the nmake and Visual Studio 8 generators please?

Best regards
David

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Newbie question, building the exe to a directory

2007-09-02 Thread Pingu

An experienced friend of mine suggested getting CMake going on this 
project I was starting at the time. Naturally, I had never heard of it 
and he spend most of his time setting up the system. He left he group 
recently and I'm a bit lost at how to do even simple things. A little 
bit of help would be great. Here goes:


Right now, it's all set up so that individual files are in source 
directories and then CMake builds the project in a separate build 
folder. We use SVN and all have the build folder ignored so that we have 
our own copy locally and just share the source files. However, we're 
making an application that uses outside files in its directory and we 
need a way to put those files in with the exe and have SVN update them. 
All I'm asking for is a way to tell the compiler (VS8) to build the exe 
in a certain folder as opposed to the build folder where the project 
files are located. It really doesn't seem like it'd be that hard, but I 
really don't understand CMake all that well right now.


Thanks, pingu.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Newbie question - how to use multiple C++ compilers?

2006-06-01 Thread Bennett Smith


Hello,

I am trying to convert our current home-brew build system to use
cmake.  One issue we have is that some libraries are built using
Visual C++ 7.1 and other libraries and executables are built using
VIsual C++ 6.0. I would like to somehow indicate in each subdirectory
which version of the C++ compiler is required, perhaps in the
CMakeLists.txt file.  Is this possible?

Many thanks

-- Bennett
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Newbie question: cmake does not have nmake generator

2009-09-09 Thread Bill Hoffman


David Aldrich wrote:

Hi
 
I am new to cmake. I have installed cmake (using 
cmake-2.6.4-win32-x86.exe) on my Win XP platform, on which I also have 
Visual Studio 2005 Prof and Visual Studio 2008 Express installed.
 
I am trying to build PLplot, whose instructions tell me to run:
 
cmake -G "NMake Makefiles" -DCMAKE_INSTALL_PREFIX=install ..
 
but I get:
 
CMake Error: Could not create named generator

-- Check for working C compiler: gcc
-- Check for working C compiler: gcc -- broken
The C compiler "gcc" is not able to compile a simple test program.
 
It appears that cmake only knows about the unix generator:
 
C:\plplot-5.9.5\buildnmake>cmake --help

[snip]
The following generators are available on this platform:
  Unix Makefiles  = Generates standard UNIX makefiles.
 
I have run Visual Studio file vcvars32.bat
 
How can I install the nmake and Visual Studio 8 generators please?

Best regards
David
 
My guess is you are using the cygwin built CMake, use the windows CMake 
from www.cmake.org.


-Bill


___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Newbie question: cmake does not have nmake generator

Hi 

> Any idea why this is happening please?

Sorry, I should have thought a little more. I deleted the contents of 
buildnmake and now CMake succeeds.

I then executed:

C:\plplot-5.9.5\buildnmake>path=...\plplot-5.9.5\buildnmake\dll;%PATH%
C:\plplot-5.9.5\buildnmake>nmake

and the nmake output terminates with:

[ 87%] Building C object drivers/CMakeFiles/xfig.dir/xfig.c.obj
xfig.c
Linking C shared module ..\dll\xfig.dll
   Creating library ..\dll\xfig.lib and object ..\dll\xfig.exp
   Creating library ..\dll\xfig.lib and object ..\dll\xfig.exp
[ 87%] Built target xfig
Scanning dependencies of target test_dyndrivers
[ 87%] Generating test_dyndrivers_dir/mem.rc
NMAKE : fatal error U1077: '.\test-drv-info.exe' : return code '0xc135'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio 
8\VC\BIN\nmake.exe"' : return code '0x2'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio 
8\VC\BIN\nmake.exe"' : return code '0x2'
Stop.

Any ideas on this one please? I started from the Visual Studio 2005 command 
line interface, but Visual Studio 8 nmake has been invoked. I wonder if that is 
causing the problem?

Best regards

David
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Newbie question: cmake does not have nmake generator

Hi Bill and Alan

Thank you both very much for answering my question. I did indeed have an old 
version of CMake, from a forgotten installation of Cygwin, and that was being 
invoked. I have now deleted that old CMake (and hopefully Cygwin as well) and 
am now truly running 2.6.4. 

C:\plplot-5.9.5\buildnmake>cmake --help
cmake version 2.6-patch 4
[snip]

However, I have now hit another problem:

C:\plplot-5.9.5\buildnmake>cmake -G "NMake Makefiles" 
-DCMAKE_INSTALL_PREFIX=install ..
CMake Error: The source "C:/plplot-5.9.5/CMakeLists.txt" does not match the 
source "/cygdrive/c/plplot-5.9.5/CMakeLists.
txt" used to generate cache.  Re-run cmake with a different source directory.

Any idea why this is happening please? Is the mention of 'cygdrive' worrying?

Best regards

David
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Newbie question: cmake does not have nmake generator

2009-09-10 Thread Arjen Markus

Hi David,

you should start cmake in a clean directory - old stuff might get in the
way otherwise, as a lot of information is being cached.

Regards,

Arjen

On 2009-09-10 10:05, David Aldrich wrote:

Hi Bill and Alan

Thank you both very much for answering my question. I did indeed have an old version of CMake, from a forgotten installation of Cygwin, and that was being invoked. I have now deleted that old CMake (and hopefully Cygwin as well) and am now truly running 2.6.4.

C:\plplot-5.9.5\buildnmake>cmake --help
cmake version 2.6-patch 4
[snip]

However, I have now hit another problem:

C:\plplot-5.9.5\buildnmake>cmake -G "NMake Makefiles"
-DCMAKE_INSTALL_PREFIX=install ..
CMake Error: The source "C:/plplot-5.9.5/CMakeLists.txt" does not match the source
"/cygdrive/c/plplot-5.9.5/CMakeLists.
txt" used to generate cache. Re-run cmake with a different source directory.

Any idea why this is happening please? Is the mention of 'cygdrive' worrying?

Best regards

David
___
Powered by www.kitware.com

Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

___
Powered by www.kitware.com

Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Newbie question: cmake does not have nmake generator

Hi Arjen

> you should start cmake in a clean directory - old stuff might get in the
> way otherwise, as a lot of information is being cached.

Yes, that was the problem. Thanks.

As I wrote in another mail this morning (the order seems to have got reversed) 
CMake now succeeds but nmake fails:

[ 87%] Generating test_dyndrivers_dir/null.rc
NMAKE : fatal error U1077: '.\test-drv-info.exe' : return code '0xc135'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio 
8\VC\BIN\nmake.exe"' : return code '0x2'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio 
8\VC\BIN\nmake.exe"' : return code '0x2'
Stop.

I am wondering whether this is to do with the dll path, but my path does start 
with:

PATH=..\..\plplot-5.9.5\buildnmake\dll;

Best regards

David
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Newbie question: cmake does not have nmake generator

2009-09-10 Thread Arjen Markus


Hi David,

this is PLplot-specific, has nothing (or at least very little) to do
with CMake. The problem is that the program that creates these driver
files needs a few DLLs and they are not yet in the DLL subdirectory.

Can you check with DependencyWalker or similar programs what DLLs
are missing? (I can not get to my notes about it from my office and
I am not sure I put the information on the Wiki yet)

Regards,

Arjen


On 2009-09-10 11:10, David Aldrich wrote:

Hi Arjen


you should start cmake in a clean directory - old stuff might get in the
way otherwise, as a lot of information is being cached.


Yes, that was the problem. Thanks.

As I wrote in another mail this morning (the order seems to have got reversed) 
CMake now succeeds but nmake fails:

[ 87%] Generating test_dyndrivers_dir/null.rc
NMAKE : fatal error U1077: '.\test-drv-info.exe' : return code '0xc135'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio 
8\VC\BIN\nmake.exe"' : return code '0x2'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio 
8\VC\BIN\nmake.exe"' : return code '0x2'
Stop.

I am wondering whether this is to do with the dll path, but my path does start 
with:

PATH=..\..\plplot-5.9.5\buildnmake\dll;

Best regards

David


___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Newbie question: cmake does not have nmake generator