Re: [CMake] Custom installation of cmake

[Raymond Wan]

Hi Mahmood,

Did you try typing "./bootstrap --help"?

Perhaps something there is what you need?

Ray



On Sun, Oct 20, 2019 at 2:19 AM Mahmood Naderan via CMake
 wrote:
>
> OK and how about custom installation path of cmake?
>
>
> Regards,
> Mahmood
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

[CMake] Fwd: Linking GSL to cmake using command line

[Raymond Wan]

Hi Sachi and everyone,

Sorry, I didn't realise her original message wasn't CC'ed to the list.
Please keep replies to the list, Sachi, unless there's a good reason
you shouldn't.  It will also allow someone to jump in if I've said
something incorrectly about your problem.

Ray


-- Forwarded message -
From: Raymond Wan 
Date: Wed, Sep 25, 2019 at 12:52 AM
Subject: Re: [CMake] Linking GSL to cmake using command line
To: Sachithra Weerasooriya 


Hi Sachi,

Then, to be frank, it's not something that CMake's users can help you
with.  It's (most probably) how the developer is using CMake to look
for GSL and you should be contacting him/her.  Generally, the end user
of program X shouldn't have to learn about CMake.  (Of course, no one
is stopping you from learning.)  The developer should be trying to fix
it, unless you happen to already be an expert on CMake.

If the developer isn't very responsive to your query, then that's a
separate issue, that's also not related to CMake...  S/he might be
happy to hear from you since it's a bug report and it can only make
program X better...I think?

Ray

On Wed, Sep 25, 2019 at 12:38 AM Sachithra Weerasooriya
 wrote:
>
> Hi Ray!
> Thank you  for your prompt reply! I appreciate it. Actually I am trying to 
> install a package that uses cmake. Although GSL is installed in my machine, 
> cmake can’t find the GSL directory.
>
> Best regards,
> Sachi
>
>
>
> Sent from my iPhone
>
> > On Sep 24, 2019, at 11:28 AM, Raymond Wan  wrote:
> >
> > Hi Sachi,
> >
> > Unfortunately, the short answer is "no".  I think you misunderstand
> > what CMake is.  One way to summarise it is that it allows developers
> > of programs to describe/explain how to compile and link software.  For
> > example, suppose there is a program X and it uses the GSL library.  A
> > programmer might use CMake to explain how GSL can link with X on Mac,
> > Linux, etc. -- across various platforms.  This will make it easier for
> > the end user.
> >
> > If you are an end user (i.e., you didn't make the program X), then you
> > need CMake isn't for you.  I'm afraid you might have to read the GSL
> > documentation for Mac, instead.  If you are the developer of X, then
> > you might want to go through the various CMake tutorials and give it a
> > try -- then, if you're still stuck, post what you got so far so that
> > someone can help you.
> >
> > Based on what you've asked, my guess is that CMake isn't what you
> > should be looking into.
> >
> > Ray
> >
> > On Wed, Sep 25, 2019 at 12:22 AM Sachithra Weerasooriya
> >  wrote:
> >>
> >> Hi CMake community!
> >> I am having trouble linking GSL to cmake using command line. I am using a 
> >> Mac. Can someone please help me?
> >>
> >> Thank you!
> >> Best regards,
> >> Sachi
> >>
> >>
> >> --
> >>
> >> Powered by www.kitware.com
> >>
> >> Please keep messages on-topic and check the CMake FAQ at: 
> >> http://www.cmake.org/Wiki/CMake_FAQ
> >>
> >> Kitware offers various services to support the CMake community. For more 
> >> information on each offering, please visit:
> >>
> >> CMake Support: http://cmake.org/cmake/help/support.html
> >> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> >> CMake Training Courses: http://cmake.org/cmake/help/training.html
> >>
> >> Visit other Kitware open-source projects at 
> >> http://www.kitware.com/opensource/opensource.html
> >>
> >> Follow this link to subscribe/unsubscribe:
> >> https://cmake.org/mailman/listinfo/cmake
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

Re: [CMake] complication issue

[Raymond Wan]

Hi Ali,

Please keep replies (to me, at least) to the CMake mailing list, as
well.  I'm not too knowledgeable with CMake and it's always useful for
all parties to have a discussion public so that others can jump in and
contribute something.

Quite frankly, your sentence below doesn't make sense to me.  I mean,
Makefiles and CMakeLists.txt are just text files.  If two Makefiles
are "running the exact commands", then they will behave exactly the
same.  The question is are the Makefiles *identical* and if not, then
you need to work backwards to where in the CMakeLists.txt has that
change been introduced.

Ray


On Tue, Mar 19, 2019 at 1:43 AM Ali Angle  wrote:
>
> Hi Raymond,
> Please see the example code attached. In simple terms Makefile generated by 
> cmake is running exactly the same commands as the Makefile file created by 
> me. But the output differs and doesn't work when build using cmake generated 
> Makefile.
>
> On Mon, 18 Mar 2019 at 20:42, Raymond Wan  wrote:
>>
>>
>> Hi Ali,
>>
>>
>> On 18/3/2019 1:52 PM, Ali Angle wrote:
>> > Issue is described over here:
>> > https://stackoverflow.com/questions/55211221/cmake-build-problem-when-building-code-for-avr
>>
>>
>> I'm not too sure what you're talking about in this posting,
>> but I am also not too familiar with AVR.
>>
>> At the beginning of your Stackoverflow post, you said, "When
>> I build using make everything works fine. but when I use
>> cmake it doesn't compile ok" and this statement isn't quite
>> clear.  If you hand-coded a Makefile, then you would compile
>> with that.  But CMake is used to create a Makefile.  When
>> you say it doesn't compile...are you saying you are having a
>> problem at the CMake step or the Make step?
>>
>> Are you comparing a Makefile that you made vs a
>> CMakeLists.txt that you made?  Or is one made by someone else?
>>
>> Ray
>>
>>
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at: 
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more 
>> information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>
>> Visit other Kitware open-source projects at 
>> http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> https://cmake.org/mailman/listinfo/cmake
>
>
>
> --
> A.A
>
>
> Regards,
> sYsTeamAngle
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

Re: [CMake] complication issue

[Raymond Wan]

Hi Ali,


On 18/3/2019 1:52 PM, Ali Angle wrote:
Issue is described over here: 
https://stackoverflow.com/questions/55211221/cmake-build-problem-when-building-code-for-avr



I'm not too sure what you're talking about in this posting, 
but I am also not too familiar with AVR.


At the beginning of your Stackoverflow post, you said, "When 
I build using make everything works fine. but when I use 
cmake it doesn't compile ok" and this statement isn't quite 
clear.  If you hand-coded a Makefile, then you would compile 
with that.  But CMake is used to create a Makefile.  When 
you say it doesn't compile...are you saying you are having a 
problem at the CMake step or the Make step?


Are you comparing a Makefile that you made vs a 
CMakeLists.txt that you made?  Or is one made by someone else?


Ray


--

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

Re: [CMake] Automatically updating Doxygen documentation and making it readily available to users with CMake

[Raymond Wan]

Hi Timothy,

This is not something I'm very familiar with, but maybe I 
can still add a little to the discussion by answering both 
of your messages together.



On 21/2/2019 10:18 PM, Timothy Wrona wrote:
Perhaps there is a standard location to "install" the 
documentation when running the install command for a project?


Either way having it as an "index.html" file somewhere on 
the hard-disk is not very intuitive. It would make much more 
sense for it to be on a web server where you can access it 
with a sensible URL.



You're right that it isn't intuitive, but then you're 
assuming that users will all install a (Apache, etc.) web 
server.  And many users do not.


If you're doing cross-platform development, then I am fairly 
sure that most of the people I know who use Microsoft 
Windows do not install a web server.


On my Ubuntu-based computer, I have installed a local 
version of the Boost library.  The HTML documentation is 
installed in:  $BOOST_ROOT/doc/html/ .  In my case, 
$BOOST_ROOT is /usr/local/boost_/, but some people 
might install it in /opt, for example.


As for your 3 questions, I don't know the definitive answer 
but my gut feeling is:




 >   1.
 >
 >   Is there a standard location to put the
documentation once it is built
 >   where it makes it very clear to the users of a
library that documentation
 >   is available for a library?



For packages installed using Ubuntu's package management 
system, documentation tends to go to /usr/share/doc/ or 
/usr/share/man/.  But I'm sure the path is different for 
CentOS, RedHat, etc.


If you're not installing software through a package manager, 
then the documentation probably goes into /usr/local or /opt 
(See: 
https://unix.stackexchange.com/questions/11544/what-is-the-difference-between-opt-and-usr-local).


For software that I've developed myself, I've placed the 
documentation together with the software, similar to the 
Boost library.  That is, within the root directory, I threw 
it into a directory called doc/.  If sysadmin access is 
required and it goes into /usr/local//, then like 
Boost, it would go inside that directory.


With other people's programs that I've downloaded myself, I 
normally look in the root directory (of that program) for a 
doc/ directory too.  So, perhaps the answer to your question 
about "standard location" is to just ask yourself if your 
role was reversed -- i.e., you're just a user -- where would 
you look for documentation?




 >   2.
 >
 >   How can I ensure that every time my library is
built, the documentation
 >   will be *automatically *updated and placed in this
standard location?



Since this is your software and you wrote the CMake file, as 
long as you've defined and then fixed the installation 
target from version to version, then it should be ok.


I don't know what kind of automation you were looking for. 
Someone still has to do a "cmake ..; make; make install" or 
something like that.  You're not talking about automation 
along the lines of some cron job, are you?




 >   3.
 >
 >   Is there any standard way to keep past versions of
documentation for
 >   reference in case someone is using an earlier
version of the library?



I think when you've asked "standard way", it sounds like 
you're looking for Doxygen and/or CMake having standardized 
the location.  But, based on my examples above, it seems it 
is OS dependent.


And it depends whether you're distributing the source files 
or the binaries only (i.e., like an Ubuntu/Debian .deb 
package).  In the case of the former, you've defined it 
using your CMake file.  In the latter case, you've compiled 
it and then wrote some instructions for Debian's package 
management software so that the documentation goes into 
/usr/share/doc, /usr/share/man/, etc.


Just my 2 cents...I'm happy to hear what others think.

Ray


--

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

Re: [CMake] My previous message

[Raymond Wan]

On 4/11/2018 4:01 PM, Osman Zakir wrote:
I tried to do it before, but it won't let me clone the 
repository without sudo for some reason.



I have little experience with Docker -- actually, none.  But 
as several people have hinted to you already, this doesn't 
seem like a CMake issue.


For example, from this statement above, it sounds like you 
have a problem with why you have to use sudo to clone the 
repository.  You got around this problem by using sudo, but 
that has opened up other problems that make you believe it 
is an issue with CMake.


Personally, I have never cloned a repository using sudo. 
"sudo" is really a last resort, and every time one has to 
use it, one should ask if there is a better way.  At most, I 
would clone it with my own account and then perform the 
installation step (i.e., "make install" using sudo).  Of 
course, if you have to use "sudo" to compile, then that's 
also an issue but not related to CMake.


Anyway, in case no one else can give you better advice than 
this, I suggest you take a step back and look at why you 
have to use sudo to clone.  This might mean that you should 
ask a Docker mailing list for help.


Ray

PS:  Apologies if something I said here is incorrect. 
Honestly, I haven't followed your problem from the very 
beginning.



--

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

Re: [CMake] Installing CMake in Ubuntu Linux from command-line via wget

[Raymond Wan]

Hi Osman,


On 30/10/2018 6:56 PM, Osman Zakir wrote:

Okay, thanks.

So how about this as the command?

"
RUN wget 
https://cmake.org/files/v3.12/cmake-3.12.3-Linux-x86_64.tar.gz 
  \

     && tar xzf cmake-3.12.3-Linux-x86_64.tar.gz  \​
     && rm -rf cmake-3.12.3-Linux-x86_64.tar.gz  \​
     && cd cmake-3.12.3-Linux-x86_64  \​
     && apt-get install \​
     && ./bin/cmake --version
"
I think I'll need the apt-get install part to install the 
library.  Is this true?



Not quite.  I think you should decide whether you want to:

a)  Install the latest version from cmake.org
b)  Install the latest version within the Ubuntu software 
repositories.


If you choose (b) then the latest version in Ubuntu 18.04 is 
CMake 3.10.2 .  In this case, the command above changes 
completely.  It is far easier but you'll also not get the 
latest version.


If you insist on the latest version, then where you have 
"apt-get install" should be replaced with commands that 
Mateusz has already said.  That is, the steps mentioned here:


https://cmake.org/install/

(Perhaps the cmake-linux.sh that Mateusz mentioned works...I 
personally haven't installed a version from cmake.org for a 
very long time, so I wouldn't know.)


Anyway, you might want to figure out which path you want first.

Ray



--

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

Re: [CMake] Ubuntu package versioning

[Raymond Wan]

Hi Alexander,

On Tue, Dec 19, 2017 at 11:39 AM, Alan W. Irwin
 wrote:
> On 2017-12-18 19:14-0500  wrote:
>
>> I'm not sure who maintains the Ubuntu cmake package, but I *just*
>> installed
>> it, and cmake --version reported 3.5.1... a little bit out of date.
>
>
> If you look at
> 
> the various Ubuntu distribution versions called xenial, zesty, artful, and
> bionic provide respectively CMake versions 3.5.1, 3.7.2, 3.9.1, and
> 3.9.5.  And similar situations occur for all other Linux distros.
>
> So if you upgrade to a later Ubuntu version you will automatically get
> access to a later CMake version. But such upgrades are non-trivial so a
> compromise that allows you to delay doing such an upgrade for a while
> would be to build and use a newer version of CMake yourself.


In addition to what Alan said, another alternative to compiling it
yourself is to install Anaconda into your home directory and then to
install cmake from that.  For example, you can see here what is
available to you:  https://anaconda.org/search?q=cmake

Ray
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

Re: [CMake] my first experiences

[Raymond Wan]

Hi Xen,


On Fri, Jun 9, 2017 at 3:40 PM, Xen  wrote:
> I just want to tell you what terrible software CMake is.
>
> The newest version won't compile on my system. The bootstrapping just won't
> complete.


Just out of curiosity but is there any reason why you need the "latest
version"?  I usually use the default version for my OS (3.6.3 on
Ubuntu, currently) and it is usually good enough for my needs.


> It took me 3 hours to compile version 2.4.0. The latest release candidate
> had been working all night and not proceeding.


The latest version of CMake is 3.9.0-rc2...

Perhaps others on this mailing list can help you with your specific
problems but I've used CMake off and on for many years and never
compiled it myself.  I've always relied on the Ubuntu package.  It's
older but usually good enough since the features I need are fairly
basic...

Good luck with it and sorry to hear you're having problems!

Ray
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Does Makefile generated by CMake support make -jN?

[Raymond Wan]

Hi Chao,


On Wed, Jul 13, 2016 at 10:54 AM, Chaos Zhang  wrote:
> I was trying to compile my project using CMake, after CMake generated
> Makefile.
> I used `/usr/bin/time -v make` to make the Makefile,  got the result:
> 'Percent of CPU this job got: 96%'.
> Then i used `/usr/bin/time -v make -j8` to make the Makefile, the result of
> CPU used is  'Percent of CPU this job got: 648%'.
> So i wonder if Makefile generated by CMake support make -jN, BTW my CPU is
> I7-4790, and after i use 'cat /proc/cpuinfo', there are 8 processors.


I'm not sure what you are asking...

You ran make with -j 8 and you got a percentage greater than 96% ...
this implies that the Makefile does support -jN, doesn't it?  If you
got 96% both times, then I would say there's a problem.

Is what you're wondering why it is 648% and not 800%?  I think that
depends on the dependencies in your Makefile.  It's possible that some
of them depend on each other in such a way that 8 parallel threads is
not possible.

Also, I can't remember the value returned by /usr/bin/time -v, but I
guess 648% is the average and not maximum.  So, perhaps there are
parts within the Makefile that only one thread could be used and then
it gets averaged out?

Ray
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Compiling binaries with cmake -- help

[Raymond Wan]

On Sat, Jul 2, 2016 at 7:38 PM, Crest Christopher
 wrote:
> Hi, thanks but I really want to compile it myself ;-) I hope someone can
> help !


To be honest, you really should contact the original developers for
help with dependencies and compiling.  Not only are they the experts
with their own programs, but they also have an interest in having
users being able to compile their programs.

Likewise, if there is a bug in their program or even their
instructions, I'm sure they would like to know (and hopefully update
accordingly).  This even includes "bugs" in their CMakeList.txt ...

(If developers don't have such an interest, then I don't know why
bother sharing code on GitHub.  So, my *guess* is that they should be
helpful if you contact them...but I could be wrong!)

Ray
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] How do you handle recursive dependencies in CMake

[Raymond Wan]

Hi Sven,


On Thu, Jun 30, 2016 at 6:40 PM, Sven Baars  wrote:
> So let's take Trilinos as an example, which is quite a big library,
> which depends on a lot of libraries as well. In every project that
> builds upon it (but does not even use functionality of any libraries),
> we would have to set: SCALAPACK_ROOT, LAPACK_ROOT, BLAS_ROOT,
> BOOST_ROOT, GTEST_ROOT, BLACS_ROOT, UMFPACK_ROOT, MKL_ROOT, etc... and
> then inside the CMakeFiles.txt do a find_package(Trilinos),
> find_package(Scalapack), find_package(LAPACK), etc... just to compile
> int main() {} with one call to a Trilinos function inside of it. I'd say
> that it should be enough to just do a find_package(Trilinos).


Perhaps I'm alone here, but I actually don't see this as being a "big" problem.

For the environment variables, you can place them all in a bash script
and source it during log in.

For all of the Find_Package calls, they only matter whenever you have
to re-run cmake.  I don't know what Trilinos is, but for something
that big, I presume it takes more time to compile it (during active
development) than to run cmake to look through all those paths...

Ray
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] How do you handle recursive dependencies in CMake

[Raymond Wan]

Hi Sven,


On Thu, Jun 30, 2016 at 4:59 PM, Sven Baars  wrote:
> This is a reply to the options that Ray gave. Here I will use the
> package dependencies C -> B -> A{1,2}:


Well, I presented some options to you.  Perhaps there are others, but
if none of them are right for you then there's nothing more I can add,
I think.


> On supercomputers it is very common that every library on the system is
> installed in a different directory. This is so every user can load their
> own version of the library without breaking the system for others.


Sure.  So, during the CMake run, you can set CMAKE_INSTALL_PREFIX to
be something like ~/lib/ or ~/mylib/ or whatever.


> Therefore, you will never find libraries that are installed in the
> standard system directories where CMake looks for the libraries. By


Well, I wasn't suggesting that you use Find_Package as-is.  I mean the
phrase "CMake looks for the libraries" isn't quite correct here since
its behaviour is affected by the Find_Package's implementation.

Presumably, you will need to write your own for the modules you're
working with.  One person would write it and this file would be
shared.

How it would work is "something like" (i.e., you need to look at how
it works yourself) the Boost library.  With that, you can set
BOOST_ROOT to override the system-installed version.  (Take a look at:
 https://cmake.org/cmake/help/v3.3/module/FindBoost.html)

I think I said this early on, but perhaps I didn't explain it very well.

Thus, each user would set an environment variable that would affect
the search path of this Find_Package that you wrote.  If this is
troublesome, then you can add some favourite paths like ~/lib/ and
~/mylib/ as default paths to the search first.

I think it is a bit unreasonable for CMake to "automatically" know
where libraries are stored for each user other than performing a
recursive search down ~/ .  (I suppose that's possible.)  To reduce
the search space for binary programs that we've installed in ~/, we
would set the PATH variable.  I don't think it's that much different
from setting something like BOOST_ROOT and then getting a Find_Package
that you've written to use this as the starting point for a search.

I mean, it seems strange to expect CMake to be able to find archive
files by itself but, by default, we do not expect the same for
executable files...

Ray
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] How do you handle recursive dependencies in CMake

[Raymond Wan]

On Wed, Jun 29, 2016 at 3:23 AM, Cfyz <cfyz...@gmail.com> wrote:
> On 28 June 2016 at 17:19, Raymond Wan <rwan.w...@gmail.com> wrote:
>> I think if I were presented with the same problem as Sven, I'd <...> Or,
>> if that wasn't possible, use ExternalProject.
>> It's inefficient in terms of disk space, but at least A (assuming A
>> depends on B) will be built correctly.
> What I'm trying to solve (and what Sven's problem looks very similar to) is
> more about keeping the information about dependencies. You've mentioned that
> yourself in the linked discussion: the real problem are projects with
> complex tree-like dependencies, more than one edge deep. And once those
> dependencies become optional and configurable, things break completely. It
> is impossible to search for the dependency you don't even know about =(.


I agree that what we're observing is a problem, but I don't think it
is that big.  There are at least 3 solutions discussed so far:

1)  The "ad-hoc" method I first mentioned by setting
CMAKE_LIBRARY_OUTPUT_DIRECTORY.
2)  ExternalProject which will grab a repository and build it.
3)  Some Find_Package () mechanism that will do a search for it.
4)  Your option of including *.cmake files that provide the paths
[sorry, I might have misunderstood it].

If we have some kind of transitive dependency:  A depends on B; B depends on C.

Then when we build A, we don't really need to know [in detail] that
this transitive dependency exists (*).  All the compiler needs to know
is where is B and where is C.  And if B and C are in the same
directory (i.e., a system-level directory), that's fine.

Suppose B and C are in two different directories.  I don't know if
it's common, but often, I see install scripts provide a symbolic link
from the system-level directory to where B and C are

In Sven's case (sorry to put you on the spot, Sven!  :-) ), the 3
options don't work because:

1)  Modules are in different source trees.
2)  Duplication between users on a super-computer.
3)  Too many combinations of Find_Package ().
4)  Seems ad-hoc?

Though not perfect, either (2) or (3) could solve Sven's problem.  For
(2), ignore duplication.  For (3), how about something like what
Find_Boost does?  It searches for system-level directories, but you
can nudge it by setting an environment variable (i.e., BOOST_ROOT)
where it will search first.  This means each user will have to set an
environment variable (or set it on the command-line of CMake with -D).

Hm, I *think* any of this is fine (for Sven's problem), but if it
isn't then perhaps I'm misunderstanding the problem...

Ray

(*)  At least, the order to the archives in target_link_libraries have
to be correct.  But that is done once by the CMakeLists.txt writer and
not something the end user needs to worry about.
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] How do you handle recursive dependencies in CMake

[Raymond Wan]

Hi,


On Tue, Jun 28, 2016 at 8:41 PM, Cfyz  wrote:
> dependencies' locations. Personally I do not agree with that as I see
> neither any way around specifying paths to dependencies not any substantial
> harm in that. Maybe I am missing something but as far as I've found there
> was not discussion about this matter before.


Actually, there has been discussions about transitive dependencies
before.  In fact, such discussions crop up once a month or two.

See for example,
http://public.kitware.com/pipermail/cmake/2016-January/062590.html
(which I did reply, also with a link to my GitHub repository with a
minimal example).  Perhaps many others before me have also done the
same.  [Again, just because I reply doesn't mean I think I'm
right...I'm learning through discussions, as well!]

In my humble opinion, Sven's problem is two-fold.  They are
inter-related, but they could be separated.  The first is the
transitive dependency and for this, if it's all within the same source
code tree then something like what I did could work.  The second is
that the dependencies are not installed in system-level directories,
even though multiple users on a super-computer need to share them.

Because of this second factor, I don't have an idea what Sven should
do.  Indeed, what you suggest could work -- as I don't have a need, I
haven't given that much thought.

I think if I were presented with the same problem as Sven, I'd ask the
system administrator to install it.  Or, if that wasn't possible, use
ExternalProject.  Yes, if there are 100 users, then there would be 100
copies of the dependency.  But, running CMake will grab the most
recent copy from the source repository.  It's inefficient in terms of
disk space, but at least A (assuming A depends on B) will be built
correctly.  I don't know if CMake's aim is to build software correctly
*and* save disk space...  :-)

Ray
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] How do you handle recursive dependencies in CMake

[Raymond Wan]

Hi Sven,


On Tue, Jun 28, 2016 at 6:03 PM, Sven Baars  wrote:
> The packages I use are installed in a non-standard path, because I don't
> have access to the system directories on most systems I work on, but are
> used by many other libraries. They are also all separate packages, not
> packages in the same source tree. I did not see my attachment on the
> mailing list archive, so instead I just put it on Github. It can be
> found here:
>
> https://github.com/Sbte/cmake-example
>
> I hope the example shows my workflow, and also what doesn't work for me.


H, in that case, I should probably remain quiet as this is not
quite something I've had to do.

Maybe the only advice I can give is, if you plan to distribute your
work to others, what are your expectations in terms of where do you
think users should install these dependencies.

For example, if it's a system-level directory, then maybe you can
consider a FIND_PACKAGE solution which has a list of default paths to
search.  When you're developing on your own computer, you just change
the default path to include paths in your home directory.

There is also the ExternalProject () directive which you could
consider [https://cmake.org/cmake/help/v3.3/module/ExternalProject.html]
.  This would retrieve the dependencies from outside sources (i.e.,
repositories) and build them.  This would keep everything within the
same build/ path and I haven't done that (and didn't mention it
before) because all of my packages are within the same source tree.

So, still not quite your situation, though.

I hope this helps!  Perhaps others can chime in and help you with
exactly what you're stuck with...

Ray
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] How do you handle recursive dependencies in CMake

[Raymond Wan]

Hi Sven,


On Tue, Jun 28, 2016 at 5:26 PM, Sven Baars  wrote:
> Hey all,
>
> Since I did not receive a reply to my previous mail, I decided to write a
> minimal example explaining my problem, where I kept al the names as I used
> in my previous mails. I hope that after seeing my example, someone can
> explain me what I am doing wrong here. I included a script that reproduces
> the problem.
>
> Cheers,
> Sven


I'm not much of an expert with CMake, but I can explain to you what
I've done, at least.

If I understand correctly, package X makes use of package Y, but
during compilation, it cannot find it?  I think what you can do
depends on whether X and Y are in two separate source trees.

If they are, then it is almost like Y is the zlib library.  Then what
you can do is, like the zlib library, install it into a system
directory (i.e., via INSTALL ()) and then X will use a FIND_PACKAGE to
look for it.

But, suppose Y isn't like zlib.  For example, it is a library that is
within the same source tree and will only ever be used by X (both of
which are written by you).  I think this is the scenario that you're
talking about?  In my case, I have done this in my CMakeLists.txt:

SET (CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR})

I guess you can set it
[https://cmake.org/cmake/help/v3.3/variable/CMAKE_LIBRARY_OUTPUT_DIRECTORY.html]
to anything so that all of the libraries will be installed into one
place without doing an INSTALL.  Of course, this directory is or
somewhere within the build/ directory.  (I suppose doing an install
into ${CMAKE_BINARY_DIR} would achieve the same thing?)

I had previously installed Y's archive into a system directory, but
besides the need to run FIND_PACKAGE, I thought it was "silly" to
install an archive into a system directory that is only used by my own
program.  Seems a bit messy and intrusive to the end-user -- my
libraries are quite unlike zlib; few chance someone else will use it
:-) .  At the very least, this approach keeps it in one place within
build/ .

I'm not sure if it is the "right" way to do it, but this is what I do
at the moment...  I hope it helps!

Ray
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] CMake download blocked by Google Chrome

[Raymond Wan]

Hi Matthew,


On Sun, Apr 10, 2016 at 10:45 PM, Matthew Rule  wrote:
> Ok thanks for the responses. I will go ahead with the download in that case.
> Sorry if the question was a little offtopic for this mailing list, I see
> it's mostly technical discussion.


...I don't know.  Your query could be "on-topic" since it at least
helps draw attention to the problem to the web masters of cmake.org.
Maybe it's nothing; or maybe a harmful file did sneak on to the site.

Anyway, not everyone will know that Google has marked the site as
"partially dangerous" since others may use other browsers (i.e., I use
Firefox and received no warning).

Ray
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] CMake download blocked by Google Chrome

[Raymond Wan]

Hi Matthew,


On Sun, Apr 10, 2016 at 10:25 PM, Matthew Rule  wrote:
> When trying to download cmake-3.5.1-win32-x86.msi from
> https://cmake.org/download/ I received the following message:
> https://i.gyazo.com/6cf9cd56e9cf1f513f649cf59f768241.png
>
> I'd assume that this message is displayed to most Chrome users (if Google
> uses and distributes a single collection of malware filter lists) so it
> should be a big concern. Is it currently safe to download software from
> cmake.org, or has someone injected malicious code into it? Why has this
> message come up? Can I ignore it safely?


I guess it is safe, but if you're not in a hurry, you can wait until
the webmasters of cmake.org (not me) resolve the issue first so that
Google removes the site from their warning list.  According to:

https://www.google.com/transparencyreport/safebrowsing/diagnostic/index.html#url=cmake.org

Google seems to have marked it as "partially dangerous".  Of course,
Google could be wrong -- I think this filter list is maintained
automatically and maybe they got the criteria wrong this time.

Ray
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Visual C++ for Linux

[Raymond Wan]

Hi Lloyd,


On Thu, Mar 31, 2016 at 12:40 PM, Lloyd  wrote:
> Hi,
>
> Microsoft announced Visual C++ for Linux. Would CMake support this?
>
> https://blogs.msdn.microsoft.com/vcblog/2016/03/30/visual-c-for-linux-development/
>
> Thanks,
>   Lloyd


Interesting developments but looking at the blog entry (which, BTW,
was posted yesterday -- you do expect other tools to respond quickly,
don't you?  :-) ), I don't see how CMake is related.

My understanding is that Visual C++ connects to a Linux server, copies
the source over, and then compiles it.  That's why openssh-server,
g++, etc. should be installed beforehand.  If Visual C++ is "aware"
that the project is managed by CMake then it could invoke CMake on the
server side first, and then compile it.

It makes me feel like your question should really be to Microsoft and
whether they support remotely invoking CMake as opposed to asking if
CMake would support Visual C++.  From the perspective of CMake, it
would be executed on the Linux server and would not need to be aware
of Visual C++.

As I'm not a CMake developer, of course, do not take my word on this
since I'm not an expert.  Perhaps others might have something else to
add...

Ray
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Shared library for a executable

[Raymond Wan]

Hi Tamás,


On Mon, Jan 25, 2016 at 7:02 PM, Tamás Kenéz  wrote:
> Gonzalo, Ray,
>
> I think your approaches are not in accordance with some CMake best practices
> (or at least what I believe they are).


Thank you for looking over my web site!  I welcome comments since I am
learning as I go along and I also don't know what "CMake best
practices" are.  There seems to be a lot of flexibility and a lot of
ways to get things wrong.


> Please take a look at Ray's example after a heavy refactor:
> https://github.com/tamaskenez/cmake-2016-jan-21-shared-lib-exe


Thanks for refactoring it!  I just realized I probably should have put
my example on GitHub.  Perhaps I'll do it instead of having just a
tar.gz file.


> These are the things I changed:
>
> - In your test executables don't compile the source files of the
> library-under-test into your test. Instead, link to the library. Reason (1)
> ODR, (2) this way you'll test the linking operation, too.


That's an excellent point!  Thanks!


> - Don't reach out from a subdirectory ('B') to include a sibling ('A'). It
> creates harmful coupling between the subdirectories. All information that
> 'B' needs to know about 'A' should be concentrated in the properties of the
> target 'A'. So you need to use commands like target_include_directories().
> - Unnecessary verbosity makes it harder to read and debug the CMakeLists.


The verbosity was a bit on purpose.  To help others follow the example
and to help me follow months after I look at it!  But, another reason
is that I have many CMakeLists.txt that are very similar.  And the
only part that is different are the filenames.  So, I do copy and
paste my CMakeLists.txt and change just all the filenames in one
place.

Perhaps it is hard to read and debug, but when almost all of my
CMakeLists.txt are the same, then it is actually a bit easier.


> - you can build and test 'A' standalone
> - you can build and test 'A', 'B' and 'X' in one project using the top-level
> CMakeLists.txt
> - you can't build 'B' standalone or can't build 'X' without 'A' and 'B'
> being there. If you need that feature, we need to add an install step to 'A'
> and 'B' and use find_package() in 'B' and 'X' on demand


Hm, I see.

However, the last point isn't what I was trying to achieve.  And I
mentioned it on the "Summary" page.

I was playing with this for a long time and did try what you suggest
above.  But, in one project, I had tree-like dependencies that
stretched for more than two levels.  (i.e., it wasn't just X needed A,
X needed B, X needed C, etc.).  So, I could have installed them into
the system, but I only needed it to compile X and cluttering a user's
system with libraries didn't seem like a good idea.

BUT, I now see a way around it.  I suppose I can install them into an
install path within the build tree.  And apply find_package () to just
within the build tree.

That would satisfy all of these criteria:

1)  A and B are independent,
2)  B can be built stand-alone,
3)  A and B are installed within the build tree,
4)  A and B are to be found with find_package (), and
5)  Only X is installed in the system-level directory (since that is
the only program that a user should run).

I think this sounds fine...  I will give it a try.  Thank you for your comments!

Ray
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Shared library for a executable

[Raymond Wan]

Hi Gonzalo,


On Mon, Jan 25, 2016 at 5:22 PM, Gonzalo <ggarr...@gmail.com> wrote:
>
>
> El 22/01/16 a las 10:50, Raymond Wan escribió:
>>
>> Hi Gonzalo,
>>
>> I recently tried doing this and wrote it up as a record for myself.
>> Of course, I don't know if it's the right way, but I'm doing it this
>> way until I figure out a better way...
>>
>> See if this helps and let me know if you figure out something better:
>>
>> http://www.rwanwork.info/sysdocs/cmake/overview/
>>
>> Ray
>
> Thanks, Ray.  Your approach is exactly the same as mine.  We already found
> out that the problem I was having with v3.4.2 is a bug in cmake, which has
> been fixed in the git repository.


You're welcome!  I wasn't following the discussion about the v3.4.2
bug so I didn't realize that was the cause.

Nevertheless, I'm glad it helped and I'll be sure to skip v3.4.2 -- thank you!

Ray
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Shared library for a executable

[Raymond Wan]

Hi Gonzalo,



On Fri, Jan 22, 2016 at 1:49 AM, Gonzalo  wrote:
> I have the need to have a shared library be created and then this same
> library be accessed by my executable.
> I want both to remain in different sibling directories and have one main
> CMakeList.txt that would call the other two CMakeList.txt (one in the lib
> dir, one in the exe dir) to build the library and the executable.
> In addition, I would like my library to be able to be compiled by itself
> (its own project).
>
> Can someone point me how to do this?  I set it up for my program with v2.8
> but now this is failing on 3.4.2.


I recently tried doing this and wrote it up as a record for myself.
Of course, I don't know if it's the right way, but I'm doing it this
way until I figure out a better way...

See if this helps and let me know if you figure out something better:

http://www.rwanwork.info/sysdocs/cmake/overview/

Ray
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Are the poor reviews of Mastering CMake Justified?

[Raymond Wan]

Hi Jake,


On Sat, Dec 19, 2015 at 5:02 AM, DJ  wrote:
> This all led me to consider purchasing the book Mastering CMake. However,
> reviews on Amazon are generally very critical of the book. It is indeed
> expensive. Should I bother to shell out for it, or do others here share this
> negative evaluation of it? I don't want to waste my money.


I've purchased the book (the older edition) and it is fine.  I mean,
I'm a bit old-school and do prefer a printed book.  Online docs seem
more of an excuse to easily swap between reading and a distraction
(i.e. Facebook) -- but that's just me.

Indeed, it is similar to the online manuals.  And those will get
updated with each subsequent version; a book will not (e-book or on
paper).

I had a hard time getting into CMake and the book isn't written like a
tutorial.  I mean, it explains the first few steps and then jumps to a
reference book (I don't have it with me, but this is from memory).  I
guess there is value in having a CMake book that is entirely a
tutorial or even one of "recipes" -- Mastering CMake (as far as I can
remember) isn't that.

For that, you'd probably have to use the Web...

Ray

PS:  I don't regret buying the book.  At the time, I was really stuck
and overwhelmed by the online documentation.  Having it printed made
it a bit easier for me.  Each person learns differently, but skimming
over the Amazon comments, they seem accurate.  Of course, buy the
latest edition if you end up buying.
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] organizing includes statements

[Raymond Wan]

Hi Owen,

Sorry to jump into the discussion, but what you're talking is
something I was thinking of just recently...

I think the choice between this:


On Thu, Dec 10, 2015 at 3:48 PM, Owen Alanzo Hogarth
 wrote:
> set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib)
> set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib)
> set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin)


and this:


> it seems like this line in your reply above
> install( TARGETS lib1 lib2 DESTINATION lib )
> install( FILES lib1/headers/lib1.h lib2/headers/lib2.h DESTINATION include )


comes down to whether you want to compile other programs with these
libraries.  If you will not, then you can set the paths to
CMAKE_BINARY_DIR, which is the path to the top of the build tree.  As
far as I know, after you compile your program, you can/should delete
the build tree (i.e., assuming an out-of-source build).

So, most likely, you'd want to pick the second option if you need the
header files and archives to build something else.  This is because
when you run cmake, you can set the prefix to install files to (i.e.,
using "make install").  In my case, I only need header files and
archives to build something within a single build (i.e., various
inter-related subdirectories, all under one CMakeLists.txt).  So, I do
something similar to the first option.

I did toy with the second option a bit but, in the end, realized that
much of what I wrote won't be reused by another project of mine.  At
least, that's my understanding of the two options above...

Ray
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Executable using a library (.a or .so)

[Raymond Wan]

Hi Franck,


On Sat, Nov 14, 2015 at 11:05 PM, houssen  wrote:
> I tested your proposal (need to add target_include_directories to find
> headers) :
> # in MyLib/CmakeLists.txt
> add_library( MyLib  libsource1.c
> libsource2.cpp )
> # in MyExe/CmakeLists.txt
> add_exectubable( MyExe exesource1.c )
> target_include_directories(myExe PUBLIC ../myLib/hdr)
> target_link_libraries( MyExe MyLib )
>
> This is working, so OK I can use that. But what if the user wants to build
> myLib as a .a or a .so ? It seems it not possible to change that from ccmake
> (I've just checked). It should be possible when using Find*.cmake, no ?


I'm not a CMake expert, but I think you will issue two add_library
()'s, one for the shared and one for static.  I don't think I can say
it any better than this:

http://stackoverflow.com/questions/2152077/is-it-possible-to-get-cmake-to-build-both-a-static-and-shared-version-of-the-sam

(even though it's 5 years old, I think it's still relevant).

If we're talking about the source code associated with the
CMakeLists.txt you're processing, then presumably you already know
about libsource1.c, exesource1.c, etc. so you don't need to do Find
them.  However, if it's a set of files, libraries, etc. that has been
installed independently of the source code in question (i.e., Boost or
something you wrote that you've required the user to have done a "make
install" beforehand), then you would issue a Find*.cmake (or write one
if it's your own libraries).

I'm not too sure about this, but I think that's the distinction
between when to use Find*.cmake and when you don't need to.


> ... But, precisely, when typing target_include_directory you need to know
> the path to headers directory (+ path to libraries directory ?): this is why
> I felt like "Okay, I need to write a FindMyLib.cmake to handle this". My
> understanding is that a  (internal or external) library is a library, so, it
> should be managed with a FindMyLib.cmake. Am I correct ? (I try to
> understand the "CMake way" to do thing - I am more an autotools user, so, I
> just try to understand CMake)


In my source code, I might have some module A rely on a module B.
However, both are within the same source tree.  So, I can do
Include_Directories () to add paths to header files or
Add_Subdirectory () to add a subdirectory to the build.  As it's all
within the same source tree, I can find them using relative path
names.

However, if it's a .h or .hpp header file that was compiled and
installed separately, then I would need to use ExternalSource () to
acquire and compile it *or* use Find*.cmake to go to system paths to
look for it.

Incidentally, I've been looking into this the past week and I don't
know if I got it right.  But to summarize, this is what I think:

1)  Include_Directories and Add_Subdirectory if the header files /
modules are within the same source tree.
2)  ExternalSource if this software is not part of the source tree and
needs to be acquired *during* the build/compilation process.
3)  use Find*.cmake if this software was acquired and built *before*
the current build/compilation process.

If you use Boost, then you would use FindBoost.cmake if you want the
user to have installed Boost separately beforehand.  You would use
ExternalSource if you want Boost to be downloaded and installed in the
same CMake binary tree as you're currently on.

Not too sure...hopefully someone can correct me!

Ray
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] Handling dependencies between projects

[Raymond Wan]

Dear all,

I know this is a frequent question on this mailing list, but I'm being
a bit overwhelmed with information and not too sure which direction I
should head.

Basically, I have executables X and Y who are each top-level projects.
They make use of library A.  Library A in turn makes use of library B.
Both A and B are libraries which are linked to, but they are also
executables -- I compile with a temporary main () function in order to
do some tests.  That is, their CMakeLists.txt generate both a library
and an executable.

So, the dependencies are like this:

X <-- A <-- B
Y <-- A <-- B

What I'm confused about are:

1)  Should all 4 have their own Project () lines?

2)  Should X and Y have ExternalProject () lines to A?

3)  Should A have ExternalProject () lines to B?

4)  Or maybe instead of ExternalProject (), I should use Add_Subdirectory ()?

5)  Or should X and Y have Target_Include_Directories () to A; should
A have a Target_Include_Directories () to B?

...or maybe something else?

What I think is that they should all have their own Project ().  And
perhaps A and B should have Install () lines that install libraries
into ${CMAKE_INSTALL_PREFIX}/lib/ and header files to
${CMAKE_INSTALL_PREFIX}/include/.  Then, X, Y, and A needs
Target_Include_Directories () to this path and *NOT* the where the
source code of A and B reside.

All this removes ExternalProject () from the picture...  It's true
what I'm including is mine but these libraries could be used
separately by other programs (i.e., Y).

I hope this is clear -- there are just too many options and the
documentation is thorough but the difference between each seems small.
At least too small for me to distinguish...

Thank you!

Ray
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] linking hared libraries

[Raymond Wan]

Hi Owen,


On Mon, Oct 19, 2015 at 8:43 PM, Owen Alanzo Hogarth
 wrote:
> Also you said the PROJECT() should only be defined once, but shouldn't each
> cmakelists.txt contain a project() or else cmake complains at me.


According to the last paragraph of:

https://cmake.org/cmake/help/v3.0/command/project.html

you only need a PROJECT () in the top-level CMakeLists.txt...

Ray
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Using add_subdirectory to manage project dependencies that aren't actually in a subdirectory

[Raymond Wan]

Hi Joe,


On Sat, Sep 19, 2015 at 6:42 AM, Joe  wrote:
> /path/to/modules/FindA.cmake:
>
> ...
> if (NOT TARGET A)
>set(PATH_TO_A ${CMAKE_CURRENT_LIST_DIR}../A)
>add_subdirectory(${PATH_TO_A} ${PATH_TO_A}/build)
> endif()
> ...
>
> This way, A' CMakeLists is invoked and the library is compiled and built.
> Then in B's CMakeLists.txt:
>
> ...
> set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH}
>${CMAKE_CURRENT_LIST_DIR}/../modules)
>
> find_package(A)
> add_executable(main_B src/main_B.cpp)
> target_link_libraries(main_B A)
> ...
>
> Is this bad practice?  I tried to figure out find_package in CONFIG mode but
> every example I've found seems complicated and obtuse.  Thank you.


I'm interested in what you find.  Until now, I've been doing what you
and losif are doing.  The reason is that the top-level program (i.e.,
Z) makes use of A and B.  But also, I want to test B independently of
Z, but I need to link in A to do it.

I'm not sure if this is relevant, but what I've been doing is
following this old thread:
http://www.cmake.org/pipermail/cmake/2010-December/041150.html .  I'm
not sure if a better way is available with the current version of
CMake...  Anyway, perhaps this post will help (it's not from me)?

Ray
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Parallel builds

[Raymond Wan]

On Wed, Sep 16, 2015 at 11:44 PM, Petr Bena  wrote:
> I would prefer a way to get cmake to generate solution files for MSVC
> in a way that these options are enabled by default. Right now I need
> to do this by hand and when I run cmake again, it overwrites the
> solution files I modified and restore back the settings that disallow
> the multithreaded builds. Basically I would like to know if there is
> some option I would add to CMakeLists.txt that would make it do so. I
> understand that this may not possible with current version of CMake
> though.


I sort of don't see this as being CMake's problem.  Suppose your
computer has 4 cores.  Do you mean you would like CMake to detect that
there are 4 cores and to change the Makefile automatically?  Someone
showed this with two Makefiles [1] -- it's an interesting solution if
you want to try to make the same pair of Makefiles with CMake.  (I
have no idea how, but I guess it's possible?)

I don't know what is the Windows equivalent, but on Linux, I've
aliased "make" to "make -j 4".  So, what you describe about "solution
files" generated by CMake that get overwritten isn't really an issue.

Or maybe I've completely misunderstood you?  Do you want CMake to
detect the number of threads and then to pass that to (a) the program
that would be generated [i.e., for its execution] or (b) the
compilation of such a program?  I've assumed you meant (b)...

Ray

[1]  
http://stackoverflow.com/questions/2527496/how-can-i-write-a-makefile-to-auto-detect-and-parallelize-the-build-with-gnu-mak
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] FindMPI

[Raymond Wan]

Hi Nico,


On Fri, Sep 11, 2015 at 4:53 PM, Nico Schlömer  wrote:
> I see from the CMake docs [1] that the recommended way for using MPI is to
> call `find_package(MPI)` and set the linker and include flags appropriately.
> On the other hand, I see from the OpenMPI specs [2] that
>
>>
>
> The Open MPI team strongly recommends that you simply use Open MPI's
>
>> "wrapper" compilers to compile your MPI applications.
>
>
> Is there a way to reconcile these two approaches?


I'm not sure what is the "right" way to do things, but FindMPI and the
Open MPI's doc doesn't really contradict with each other.

If you look at the source for FindMPI.cmake, the variable for
MPI__COMPILER gets set to the path of the wrapper.  So, the
wrapper is found.  Honestly, I've never tried replacing the compiler
in my CMake with this wrapper, without setting any libraries...it
might work?

CMake is suppose to be for cross-platform development.  Some other
system might have MPI but no wrapper compiler.  So, perhaps for this
reason, it's a good idea not to rely on the wrapper?

Maybe you could use the wrapper and if MPI__COMPILER is not set,
then set the library, etc. the CMake way?

As for the Open MPI's suggestion, I don't think that paragraph means
that they suggest it over CMake's method.  I think what it is
suggesting is to use the wrapper over trying to worry about the
libraries and options "manually" -- which is a pain.

Ray
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] CMake Error at build/modules/add_boost.cmake:156 (message):‏

[Raymond Wan]

Hi Sonya,


On Sat, Aug 15, 2015 at 10:12 AM, Sonya Blade
sonyablade2...@hotmail.com wrote:
 Thank you in advance, your guess is correct Cmake module downloaded the
 boost and tried to compile it.
 Much more interestingly, it has extracted the current compiler suit on my
 machine (GCC 4.7.1) and downloaded
 the appropriate boost version boost_1_55_0_GNU_4_7_1 then it get stuck
 with previously stated message in CMake-GUI.


I suppose there are a few things you could try.  One is try using
CMake on the command-line.  Clone the repository and from another
directory, run cmake path to the top-level CMakeLists.txt.

I just tried and this is what I got:

...
-- Downloading boost 1.55.0 to /tmp/test/build
-- Extracting boost 1.55.0 to /tmp/test/build/boost_unzip
-- Building b2 (bjam)
-- Boost linking: libs static , C++ runtime shared
-- Building date_time:
./b2;link=static;threading=multi;runtime-link=shared;--build-dir=Build;stage;-d+2;--hash;variant=release;cxxflags=-fPIC;cxxflags=-std=c++11;-sNO_BZIP2=1;--layout=tagged;toolset=gcc-4.9
-- Building test:
./b2;link=static;threading=multi;runtime-link=shared;--build-dir=Build;stage;-d+2;--hash;variant=release;cxxflags=-fPIC;cxxflags=-std=c++11;-sNO_BZIP2=1;--layout=tagged;toolset=gcc-4.9
-- Building program_options:
./b2;link=static;threading=multi;runtime-link=shared;--build-dir=Build;stage;-d+2;--hash;variant=release;cxxflags=-fPIC;cxxflags=-std=c++11;-sNO_BZIP2=1;--layout=tagged;toolset=gcc-4.9
-- Building system:
./b2;link=static;threading=multi;runtime-link=shared;--build-dir=Build;stage;-d+2;--hash;variant=release;cxxflags=-fPIC;cxxflags=-std=c++11;-sNO_BZIP2=1;--layout=tagged;toolset=gcc-4.9
-- Building filesystem:
./b2;link=static;threading=multi;runtime-link=shared;--build-dir=Build;stage;-d+2;--hash;variant=release;cxxflags=-fPIC;cxxflags=-std=c++11;-sNO_BZIP2=1;--layout=tagged;toolset=gcc-4.9
-- Boost version: 1.55.0
-- Found the following Boost libraries:
--   date_time
--   unit_test_framework
--   program_options
--   system
--   filesystem
...

So, at least you can see how far it got (I've never used CMake-GUI
before, but I presume such verbose information is being hidden?).


 At the end of it since there is not error reporting on open-license-manager
 Cmake module side of does that mean
  that this discrepancy is on boost side ? I hardly believe that it is on
 boost side because boost is more stable toolkit
 and is tested with numerous volunteers over the years.


No, that isn't what my previous message implied.  Boost is probably
fine; I've installed 1.55 before with no problems.  Though that
doesn't mean it must work on every possible configuration, I guess it
is less likely that is the problem.

One possible problem is that your version of GCC is too old.  It is
4.7.1?  That seems to be a June 2012 release
[https://gcc.gnu.org/gcc-4.7/].  Boost 1.55 is from November 2013
[http://www.boost.org/users/history/version_1_55_0.html].

Close enough?  Possibly, but I've had problems with Boost before with
a slightly older compiler.

As you can tell from the output above, I got past where you were by
using GCC 4.9 .


 the Intel, gcc, sun etc.. and uses it for some
 code execution, but still doesn't explain your catch about semi column at
 the middle, so I'm surprised as well.


Seems I was barking up the wrong tree.  I got past where you are
without changing the CMakeLists.txt (NB:  Where you're stuck isn't the
file you sent but build/modules/add_boost.cmake, line 156).


 CMakeLists.txt and bootsrap.sh, I'm sure that trained eye
 will cath the malfunctioning immediately, can you simply point out at which
 direction I'm supposed to head forward?

 P.S. Is there a method to debug those type of scripts during execution?


Again, I don't think the problem is with bootstrap.sh .  That's part
of Boost and everyone who installs Boost must run it.  I'd be a bit
surprise if you caught something that no one else had.

I think the problem is with add_boost.cmake in the software you're
trying to install.  And the problem might not be with that file per
se, but with the compiling step and that *maybe* it is failing with an
older compiler.

You can add MESSAGE () lines [see the CMake documentation] within
add_boost.cmake to make sure various values are set correctly.  But, a
more fruitful direction might be to go into the directory where Boost
was downloaded and unzipped and then try to compile it using Boost's
installation instructions (see its web site).  Whether you succeed or
fail, you'll probably have a better idea of what (i.e., the program
you're trying to install, its CMakeLists.txt, or Boost) you should be
looking at.

Hope this helps and good luck!

Ray
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html

Re: [CMake] CMake Error at build/modules/add_boost.cmake:156 (message):

[Raymond Wan]

Hi Sonya,


On Fri, Aug 14, 2015 at 12:46 PM, Sonya Blade
sonyablade2...@hotmail.com wrote:
 Where do you see all of this, I couldn't even make out single meaningfu
 sentence out of it.
 The only  thing that I can understand is that bootstrap cmake file is
 executed but bootstrap.sh
 file is failing. I don't even understand from where and how boost has
 dependency on bootstrap.
 Cmake GUI downloaded the boost, does that mean that I have downloaded also
 the bootstrap
 automatically? At the attachment you can find the fulll error log during
 that execution,


I don't know the program you are trying to compile, but bootstrap.sh
is how Boost compiles itself.  i.e., it is included in the Boost
distribution.  See:

http://www.boost.org/doc/libs/1_55_0/more/getting_started/windows.html#simplified-build-from-source

Without looking at the CMake module myself, I guess it has gone off
and downloaded Boost, unpacked it, and is trying to compile it using
the bootstrap.sh / bootstrap.bat command and is failing.  Sounds like
a problem with the developers of the program and how they made the
CMake module?

You could probably look at the lines in the modules, according to the
error message.  I'm not sure if it's just a problem of the formatting
of the error message, but this looked funny to me:

 Failed running ./bootstrap.sh;--with-toolset=gcc:

--with-toolset=gcc is an argument to the bootstrap.sh script.  Why is
there a semi-colon between them?

But maybe this is nothing...

Ray
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] on cmake supporting one arch per project (from CMake IR)

[Raymond Wan]

On Wed, Aug 5, 2015 at 7:10 AM, Scott Aron Bloom sc...@towel42.com wrote:
 ===
 IMO, this is one of the biggest shortcomings of CMake.  I understand the 
 heritage of the CMake world being make file based..  I really do.. And I 
 love having a true out of source make file generator for when I am doing my 
 Linux based development.  And I don’t mind having a src tree, a build, a 
 build.rel, build.32 and a build.rel.32 etc etc for every possible 
 configuration I need.

 However, when on windows, in VS, having at a minimum of two build directories 
 (64 vs 32) is a major downside of CMake.

 I understand if its not in the 3.X timeframe, as I would expect it to be a 
 major change.. But IMO, being able to have architecture as well as build 
 types in one VS project (as well as xcode) would be a major improvement for 
 the community.
 Scott


I don't do any Windows development, so I didn't realize this.  But to
change CMake (even 4.x) to accommodate this seems strange to me.  I
mean, for the Linux/Unix developers out there, it works.  While
there was an earlier argument that the vast majority of users are
Windows-based, if we consider just developers, then I don't think the
difference is that large.

In any case, as alluded to in the other thread, why not develop a
Windows-way of creating CMakeLists.txt -- i.e., create another project
(WMake or WCMake :-P ) that generates partially compatible
CMakeLists.txt ...  Or maybe VS should be including this as a feature
in their IDE, instead?

Alternatively, perhaps we should just admit that Windows and
Linux-based development are different.  And CMake supports
cross-platform development (including Windows) for Linux-based
developers.  Not suggesting it should turn away Windows-based
developers, but just admit that it was created with a Linux/Unix
mindset (for better or worse) and can't satisfy all development
paradigms...

Ray
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] on cmake supporting one arch per project (from CMake IR)

[Raymond Wan]

On Wed, Aug 5, 2015 at 8:23 AM, Scott Aron Bloom sc...@towel42.com wrote:
 I understand.. However, my point are these.

 First, its no longer just windows, its windows and mac using XCode.
 Second, VS and XCode ALREADY support this feature in their IDE.  In NON CMake 
 created project systems, I can have in 1 project, Arm, Android, Windows 
 Phone, x86 and x64.  Where some applications in the project get built, others 
 don’t, and every library can get built with different options.  This isn’t a 
 CMakeLists.txt issue, it’s a Solution output from Cmake issue.
 Third, its on linux as well, more and more IDEs support multiple targets and 
 platforms for a given project.  Eclipse, and I believe Qt Creator (though I 
 could be wrong) to name two popular ones.


H, well, this last point raises the question of whether the
support you're asking is best served by the IDE developers by
wrapping around CMake (or some other build tool).


 Fourth, just because it was this way doesn’t mean it should always be this 
 way, that’s a pretty depressing point of view to take on.
...
 All we are asking for (and we do realize its not trivial to implement) is to 
 generate both multiple configuration and targets.


It is a depressing view and not quite what I was suggesting.  It's
more like was this way is working for some people already.

The new feature that you and some others are asking for seems to be a
lot of work (NB:  I'm not a CMake developer).  And it *feels* like
that this is something that either the build tool could support or
maybe even the IDE.  As the IDE here is closed source and doesn't
permit changes, then changing the more open build tool is the next
logical step.  But if effort is put into making some CMake 4.0 and
suddenly VS's IDE puts what you desire out within the IDE, then there
will be no users.  Or, not enough to justify the effort...

Again, I'm not a Windows developer, but would this statement be
correct?  Does VS or Xcode permit plugins to be created by the
community so that maybe one could be made to wrap around CMake?

Ray
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] CMake IR

[Raymond Wan]

Hi Máté,


On Wed, Jul 29, 2015 at 3:49 PM, Nagy-Egri Máté Ferenc cmake@cmake.org wrote:
 I wanted to ask your opinion on something that has been troubling me since…
 well, ever since I started using CMake. I have not found a single person
 alive who would have said:

 “The script language of CMake is nice, intuitive and productive. Authoring
 scripts is easy, and writing custom macros is not difficult either.”


I'm not much of an expert wih CMake but when someone says I have not
found a single person alive..., I would usually counter by asking how
many people you've asked?  :-)


 Initial feedback in my vicinity was favorable, even those with zealous CMake
 opposition aggreed this were something awesome to pull off (though they
 expressed their disbelief in Kitware and the community approving such a
 radical change). This mail along with the document only intends to get the
 ball rolling and hopefully manifest in something similar, starting with
 CMake 4.0 perhaps.


I for one am quite happy with CMake.  We can point fingers at
technology (i.e., which programming language is better or worse), but
in the end, it's really the community support (IMHO).  And if I'm
stuck with CMake, I can usually find answers to most of my problems on
this e-mail list or by searching Google.

If you want to refactor CMake along these lines:

 There are gazillions of scripting languages one could have chosen for
 CMake (Python, Perl, Ruby, Powershell, Bash, etc.)

I have a question for you.  Why introduce them as CMake 4.0?  Why not
start a new project from scratch and give it a new name.  Why take
over the name of an already working tool?  I mean, it's like
complaining about Perl (apologies to Perl lovers...just an example!)
and wanting to rewrite it from scratch.  Up to a point, it is better
to come up with new name...if you think you can do it better.

I honestly don't think CMake is broken.  Perhaps it's because I came
from Makefiles and then Autotools -- the latter was a nightmare!
Perhaps one possible improvement to CMake might be to improve the
documentation a bit so that maybe there's more information on how to
*write* modules (as opposed to using modules).

Ray
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] cmake linking errors in simple project

[Raymond Wan]

Hi Owen,


On Mon, Jul 6, 2015 at 3:48 PM, Owen Alanzo Hogarth gurenc...@gmail.com wrote:
 I created this simple project but I am having linking errors. Everything
 builds correctly but when I try to add my lib to my main.c cmake complains
 about linking errors.

 Here's what the project looks like: http://pastebin.com/22bCsuiE

 if i #include time_utils.h in my main.c I get this error:

 Scanning dependencies of target launcher
 [ 50%] Building C object CMakeFiles/launcher.dir/main.c.o
 /Users/xx/project/main.c:2:10: fatal error: 'time_utils.h' file not found
 #include time_utils.h

 if I remove that line from the main.c it builds properly. I though adding
 this line TARGET_LINK_LIBRARIES(auncher time_utils) to my cmakelists.txt it
 would find the library but seems not. How can I make sure that the library
 is found and properly linked?


Perhaps you can try adding:

INCLUDE_DIRECTORIES (path to where time_utils.h is)

It looks like the problem is with compiling main.c.  That's when it is
looking for the header files.  It isn't linking yet.  That is what
TARGET_LINK_LIBRARIES is for.

Not sure if this is the right solution, but maybe you can give it a
try; that is what I'm doing.

Ray
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] finding boost

[Raymond Wan]

Hi Dave,


On Tue, Mar 3, 2015 at 6:20 PM, Dave Yost d...@yost.com wrote:
 I’m having trouble with the find_package documentation w.r.t. boost.

 I can’t divine how to get find_package to look for boost in various places it 
 might be on the various systems where we do builds. I know boost looks in 
 several places, but I need to add to that list.

 Boost might be in any of these places
  /usr/local/include/boost
  /usr/local/boost/1.57.0/include
  /usr/local/boost/1.56.0/include   etc.
  /opt/local/include/boost
  
 /opt/local/var/macports/build/_private_tmp_boost149_boost/boost/work/boost_1_49_0/boost/

 I tried modifying this in various ways according to the docs to no avail.

 find_package(Boost ${BOOST_VERSION} EXACT
 COMPONENTS filesystem program_options serialization system
 REQUIRED)


If I'm not mistaken, the user can give hints to FindBoost via the
BOOST_ROOT environment variable.  Regardless of whether a user is
using CMake or not, s/he should be setting this environment variable
anyways.  Take a look at this:

http://www.cmake.org/cmake/help/v3.0/module/FindBoost.html

In particular, the third green-background section on that page.

Ray
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Include_directories looks for Boost twice / Problem with if statement

[Raymond Wan]

Hi Jakub,


On Fri, Dec 7, 2012 at 4:46 PM, Jakub Zakrzewski jzakrzew...@e2e.ch wrote:
 Hi
 Did you think about something like this:

 ADD_DEFINITIONS (-DBOOST_ALL_NO_LIB)
 SET (BOOST_ROOT $ENV{BOOST_ROOT})
 SET (Boost_NO_SYSTEM_PATHS ON)
 SET (Boost_USE_MULTITHREADED ON)
 SET (Boost_USE_STATIC_RUNTIME OFF)
 IF (TARGET parent)
 FIND_PACKAGE (Boost 1.42.0 REQUIRED COMPONENTS system)
   IF (Boost_FOUND)
 LINK_DIRECTORIES (${Boost_LIBRARY_DIRS})
 INCLUDE_DIRECTORIES (${Boost_INCLUDE_DIRS})
 TARGET_LINK_LIBRARIES (parent ${Boost_LIBRARIES})
   ENDIF ()
 ENDIF (TARGET parent)


How embarrassing...yes, what you suggested of just putting the search
in the IF statement worked.  Unfortunately, getting it right made me
realize I had problems elsewhere in my CMakeLists.txt (in particular,
it wasn't conditionally defining the target properly).

In the end, I added:

IF (${PROJECT_NAME} STREQUAL )
PROJECT (child CXX)
ENDIF (${PROJECT_NAME} STREQUAL )

and likewise to the ADD_EXECUTABLE () in all of my CMakeLists.txt.  I
don't know if this is the right way to do it, but it seems ok so
far...

Yes, in hindsight, what you suggested was obvious but I was so fixated
on something more complicated; the obvious eluded me!  Thank you for
your help!

Ray
--

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] Include_directories looks for Boost twice / Problem with if statement

[Raymond Wan]

Hi all,

I have two CMakeFile.txt's for a C++ project where one includes the
other.  In both cases, I'm searching for Boost.

So, to make this easier, suppose I call one project parent and the
other child such that parent's CMakefile.txt has:

INCLUDE_DIRECTORIES (child)

where child is a subdirectory.  Both have:

ADD_DEFINITIONS (-DBOOST_ALL_NO_LIB)
SET (BOOST_ROOT $ENV{BOOST_ROOT})
SET (Boost_NO_SYSTEM_PATHS ON)
SET (Boost_USE_MULTITHREADED ON)
SET (Boost_USE_STATIC_RUNTIME OFF)
FIND_PACKAGE (Boost 1.42.0 REQUIRED COMPONENTS system)
IF (Boost_FOUND)
  IF (TARGET parent)
LINK_DIRECTORIES (${Boost_LIBRARY_DIRS})
INCLUDE_DIRECTORIES (${Boost_INCLUDE_DIRS})
TARGET_LINK_LIBRARIES (parent ${Boost_LIBRARIES})
  ENDIF (TARGET parent)
ENDIF ()

(In the subdirectory child, I check for the target child instead.)

The reason I have to repeat it twice is because both parent and child
has a main ().  parent has the one for the entire project; if I want
to do unit testing on child, then I compile in child's build directory
using its main.

I hope everything so far is ok.  The problem is that when I run the
CMakeFile.txt of parent, it ends up checking for Boost twice.

There's no harm to it and I had left it alone for a while.  Then, I
thought I could use an if statement inside child to prevent it from
checking again.  Inside, child, none of these seem to work:

IF (NOT DEFINED Boost_FOUND)
IF (NOT Boost_FOUND)

So, while my question is about Boost, I guess it is irrelevant to
boost...seems to be a problem with my understanding of variables and
if statements.

Any suggestion on what I'm doing wrong?  Or am I going at it wrong and
I need to rethink what I'm doing?

Thank you!

Ray
--

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] how to inherit includes from other directories

[Raymond Wan]

Hi Glenn,


On Wed, Sep 7, 2011 at 20:36, Glenn Coombs glenn.coo...@gmail.com wrote:
 Could you not create a file in each subdirectory called something like
 header-deps.cmake ?  This file would contain the include_directory()
 commands necessary for using this module, plus include() commands of other
 modules that it depends on.  So for your example:

 # utils/b/header-deps.cmake
 include_directories(...)
 include(${CMAKE_SOURCE_DIR)/utils/a/header-deps.cmake)

 # utils/a/header-deps.cmake
 include_directories(${CMAKE_SOURCE_DIR}/common/foo)

 Then you can just do include(${CMAKE_SOURCE_DIR}/utils/b/header-deps.cmake)
 and it will add everything that B needs including all its dependencies.


My understanding of Victor's question is that he would like (and I
agree, it would be nice) for these dependencies to be determined by
CMake auto-magically.  So, whether we add include_directories () to
the CMake file or have a header-deps.cmake file is perhaps not as
important (though, your suggestion would reduce the amount of clutter
in the CMakeLists.txt file).

Perhaps a script is more suitable for this task?  That is, it would
walk through the directories and update each directories'
header-deps.cmake.  Surely, if a script is used, it would be less
error-prone to have the script update an external file than the
CMakeLists.txt file itself.

Fortunately for me, the depth of my directories is not as deep as
Victor's, so I'm not quite there yet.  But perhaps later...

Ray
___
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] how to inherit includes from other directories

[Raymond Wan]

Hi Victor,


On Wed, Sep 7, 2011 at 05:39, Victor Yankee
victor.whiskey.yan...@gmail.com wrote:
 There may 3 or 4 levels. At the top level, I would very much like to avoid
 needing to know all the dependencies at all the lower levels and
 exhaustively listing each one in an  'include_directories()' command.

 If utils/B.h needs utils/A.h which needs foo/Z.h, then in my top-level
 directory (that only needs to know about B.h)  what does its CMakeLists.txt
 look like? I would like to just be add_includes(utils/B) and have cmake
 figure out it also needs utils/A and foo.


I see what you mean now.  David's reply says it better than I ever could...

The only thing I can add is that I have the same problem as you.  :-)
Many include_directories (), even for those that are more than one
degree of separation away...  I've since given up and just have a long
list of include_directories ()...

Ray
___
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] how to inherit includes from other directories

[Raymond Wan]

Hi Victor,


On Sat, Sep 3, 2011 at 02:27, Victor Yankee
victor.whiskey.yan...@gmail.com wrote:
 build/
 src/
   utils
   a
  A.h
  unittest_a.cpp

   b
  B.h   // needs a.h

  unittest_b.cpp

   common
   c
 C.h  // needs A.h and B.h
 testit.cpp   // needs C.h, B.h and A.h


 The directory src/utils/a has a header file A.h. Likewise src/utils/b has a

 header file B.h that #includes a.h.
 Finally, c has a header file C.h that #includes a.h and b.h.


 This is just a short example of my large project. In reality there are other
 directories and levels of subdirectories.


 What can I do in the local CMakeLists.txt files so that the directories
 where the header files live are automatically made part of the others as
 needed,
 so I do not have to keep remembering all of them for every header-only

 library all the way down the dependency chain?



I'm not much of a CMake expert, but it sounds like something I've done
and I think the INCLUDE_DIRECTORIES command is all you need:

http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:include_directories

So in each of:

src/utils/a
src/utils/b
src/common/c
src/

you would have a CMakeLists.txt .  The first 3 performs the unit
testing.  And the top-level one in src/ is the one that builds your
executable.  In the CMakeLists.txt that refers to the header file in
another directory, you would put INCLUDE_DIRECTORIES.

You would then tie up their dependencies using ADD_DEPENDENCIES so
that an executable is made once something else is made:

http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:add_dependencies

I *think* that is all you need.  I've also used ADD_SUBDIRECTORY but
I'm not too sure if you need it too in your situation.

Hope this helps!

Ray
___
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] GraphViz module?

[Raymond Wan]

Hi all,

I was wondering if there is a GraphViz module that is included with
cmake.  I'm using an older 2.8.2 and can't seem to find such a module
and I'm wondering if my installation is just missing it.  I looked at
the recent cmake docs and it seems that it doesn't exist?

I did a search and came across this as one of my top hits:

http://trac.mi.fu-berlin.de/seqan/browser/trunk/seqan/util/cmake/FindGraphviz.cmake

Seems that it isn't officially part of cmake?  Thank you!

Ray

PS:  I realize that there is no reason why cmake has to have a
graphviz module; but since there is a --graphviz argument to cmake, I
thought there ought to be a FindGraphviz.cmake somewhere too and maybe
I'm just missing it.
___
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] CPack -- adding license to files

[Raymond Wan]

Hi all,

I was wondering if there is an easy/automated way that I can get CMake
or CPack to add a license to every source file prior to distribution
of the source.  Of course, I mean that I would provide the wording of
the license and all it does is copy this license to the top of each
source file in a way that is specific to the language (ideally).
i.e., using // for C++ source files.

It would be nice if it could also update dates too, but that's more of
a wishlist.  (i.e., changing Copyright 2011 to Copyright
2011-2012)

Thank you!

Ray
___
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] Sharing configuration files?

[Raymond Wan]

Hi all,

I'm having a problem which I can't quite figure out how to solve.
Basically, I have C++ source code in two directories, each for a
different class.  Let's say:

src/X
src/Y

Each one makes a different class but ultimately X makes use of Y
(i.e., an instance of Y is a variable within X's definition).
Separating them allows me to test Y independently.

So, Y uses CMake to locate the zlib library and whether or not it is
found is passed to Y's source code via a configuration file.  i.e., I
have:

#cmakedefine ZLIB_FOUND 1

in the configuration file which is created like this in CMakeLists.txt:


CONFIGURE_FILE (
  ${PROJECT_SOURCE_DIR}/Config.hpp.in
  ${PROJECT_BINARY_DIR}/Config.hpp
  )
INCLUDE_DIRECTORIES (${PROJECT_BINARY_DIR})


I think/hope so far things are ok...  I can compile Y and run it with
no problems.  The problem is that X needs access to this generated
configuration file, too.  At the very least, it needs to know the size
of an instance of Y in order to allocate memory for it.  So, some how,
I need to include it in.  If I wanted Config.hpp.in (or anything in
its directory) is no problem -- INCLUDE_DIRECTORIES () seems to do the
trick.  But is it possible for me to indicate in X's CMakeLists.txt
where Y's generated configuration file will be?

If my only option is to dump the created configuration files into one
place (i.e., some global directory for generated configuration
files), I can accept this.  But even so, I don't know how I can
#include them in...

Does anyone have any ideas?  Thank you!

Ray
___
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] Sharing configuration files?

[Raymond Wan]

Hi Hendrik,

Thank you for the suggestions!


On Tue, Jun 7, 2011 at 17:02, Hendrik Sattler p...@hendrik-sattler.de wrote:
 Zitat von Raymond Wan r@aist.go.jp:
 I think/hope so far things are ok...  I can compile Y and run it with
 no problems.  The problem is that X needs access to this generated
 configuration file, too.  At the very least, it needs to know the size
 of an instance of Y in order to allocate memory for it.

 Did you consider alternatives like giving Y a static function that returns a
 new instance of Y? That makes your problem void.
 If this is all within a project that is not going to be separated later,
 just put the common configuration into the parent directory of both


Hm, I never thought of the first option!  So if I am understanding
your suggestion correctly, this basically means that in X's class
definition, it has an entry like:

Y* instance_y;

i.e., just a pointer to it.  And then X doesn't need to worry about
the size of Y.  I might consider that...

As for your second option, yes, they are all within the same project
-- it's just one isn't a subdirectory of the other (they're siblings).
 I honestly thought that it was bad practice to have generated
configuration files outside of the build directory.  But if it is ok,
I might give this second option a try if the first one doesn't work
out.

Actually, my many configuration files is becoming a mess so that first
option is sounding more and more appealing.  :-)  Thank you!

Ray
___
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] Sharing configuration files?

[Raymond Wan]

Hi Hendrik,


On Tue, Jun 7, 2011 at 17:17, Hendrik Sattler p...@hendrik-sattler.de wrote:
 Zitat von Raymond Wan r@aist.go.jp:
 Hm, I never thought of the first option!  So if I am understanding
 your suggestion correctly, this basically means that in X's class
 definition, it has an entry like:

 Y* instance_y;

 i.e., just a pointer to it.  And then X doesn't need to worry about
 the size of Y.  I might consider that...

 Yes, that's what I meant.


Thanks -- sorry, I was just checking.  :-)


 As for your second option, yes, they are all within the same project
 -- it's just one isn't a subdirectory of the other (they're siblings).
  I honestly thought that it was bad practice to have generated
 configuration files outside of the build directory.  But if it is ok,
 I might give this second option a try if the first one doesn't work
 out.

 I assume you have a toplevel CMakeLists.txt in src/ anyway. Or do you run
 cmake for each?


Uh-oh...now I see what I'm doing wrong!

No, I don't run cmake for each but my toplevel CMakeLists.txt is
inside src/X.  Now I see what I'm doing wrong; it should be in src/.
I'll give this a try first, then.  Can't believe I missed it all this
time...

Thank you for your help!

Ray
___
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] Dependency problem with 2.8.0 (but not 2.8.2+)

[Raymond Wan]

Hi all,

I'm having a problem with cmake giving me an error about attempting to
add a Boost library to a target.  However, I have confirmed that my
CMakeLists.txt works fine in 2.8.2 and 2.8.4; however, it doesn't work
in 2.8.0.  Unfortunately, I'm trying to get it work on a machine
running on 2.8.0 and before doing a user install of cmake 2.8.4 (I'm
not a sysadmin of this machine), I was wondering if I can fix my
problem another way.

Actually, I'm also curious if I'm just doing something wrong and
2.8.2+ has just been lenient on me so far...

Basically, I have three parts:  prog, func1, and func2.  They depend
on each other like this:

prog -- func2 and func1
func2 -- func1

That is, prog depends on both func1 and func2; func2 depends on func1.
 Each one has a main () test driver to perform module-level testing,
but the most important main () is in prog.

The 3 CMakeLists.txt are as follows [I've cut out things which I think
aren't relevant to keep this message short].  Also,
ADD_SUBDIRECTORY_ONCE adds a subdirectory once to the list of included
directories (from [1]).


##  prog
IF (NOT TARGET main)
  ADD_EXECUTABLE (main ${MAIN_SRCS})
  TARGET_LINK_LIBRARIES (main func1_ar func2_ar)
ENDIF (NOT TARGET main)

IF (NOT TARGET main_ar)
  ADD_LIBRARY (main_ar ${MAIN_SRCS})
ENDIF (NOT TARGET main_ar)

INCLUDE_DIRECTORIES (func1 func2)
ADD_SUBDIRECTORY_ONCE (func1)
ADD_SUBDIRECTORY_ONCE (func2)
ADD_DEPENDENCIES (main func1)
ADD_DEPENDENCIES (main func2)


##  func1
IF (NOT TARGET func1-test)
  ADD_EXECUTABLE (func1-test func1-main.cpp ${FUNC1_SRCS})
ENDIF (NOT TARGET func1-test)

IF (NOT TARGET func1_ar)
  ADD_LIBRARY (func1_ar ${FUNC1_SRCS})
  SET_TARGET_PROPERTIES (func1_ar PROPERTIES OUTPUT_NAME func1)
ENDIF (NOT TARGET func1_ar)

##  Check for Boost (not shown)

MESSAGE (** Checking Boost in func1)

IF (Boost_FOUND)
  IF (TARGET func1-test)
LINK_DIRECTORIES ( ${Boost_LIBRARY_DIRS} )
INCLUDE_DIRECTORIES (${Boost_INCLUDE_DIRS})
TARGET_LINK_LIBRARIES (func1-test ${Boost_LIBRARIES})
  ENDIF (TARGET func1-test)
ENDIF()



##  func2
IF (NOT TARGET func2-test)
  ADD_EXECUTABLE (func2-test func2-main.cpp ${FUNC2_SRCS})
ENDIF (NOT TARGET func2-test)

IF (NOT TARGET func2_ar)
  ADD_LIBRARY (func2_ar ${FUNC2_SRCS})
  SET_TARGET_PROPERTIES (func2_ar PROPERTIES OUTPUT_NAME func2)
ENDIF (NOT TARGET func2_ar)

INCLUDE_DIRECTORIES (../func1)
ADD_SUBDIRECTORY_ONCE (../func1 ${CMAKE_CURRENT_BINARY_DIR}/func1)
ADD_DEPENDENCIES (func1-test ../func1)


When I run cmake 2.8.0, I get this output:

-- The CXX compiler identification is GNU
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Boost version: 1.46.0
-- Found the following Boost libraries:
--   program_options
--   system
--   filesystem
** Checking Boost in func1
** Checking Boost in func1
CMake Error: Attempt to add link library
/usr/local/boost_1_46_0/lib/libboost_program_options.a to target
func1-test which is not built by this project.
CMake Error: Attempt to add link library
/usr/local/boost_1_46_0/lib/libboost_system.a to target func1-test
which is not built by this project.
CMake Error: Attempt to add link library
/usr/local/boost_1_46_0/lib/libboost_filesystem.a to target
func1-test which is not built by this project.
-- Configuring incomplete, errors occurred!

With cmake 2.8.2 (and 2.8.4), I get this:

-- The CXX compiler identification is GNU
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Boost version: 1.46.0
-- Found the following Boost libraries:
--   program_options
--   system
--   filesystem
** Checking Boost in func1
-- Configuring done
-- Generating done
-- Build files have been written to: /home/rwan/tmp/cmake/prog/build


So, there are no errors with 2.8.2+.  But also of interest is that **
Checking Boost in func1 appears once here but twice with 2.8.0, which
I thought was strange...

If this is indeed a bug in 2.8.0 that has since been fixed, then I'm
quite happy to just make the cmake minimum requirement to 2.8.2 and
leave it at this.  :-)  But I am now wondering if there is something
that I've done in my CMakeLists.txt that is wrong that I should be
correcting.

I'd appreciate any suggestions and sorry for the long posting!  Thank you!

Ray


[1]  http://www.cmake.org/pipermail/cmake/2010-December/041150.html
___
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] cmake with LaTeX [UseLATEX.cmake]

[Raymond Wan]

Hi Ken,

Sorry for not replying, but this message of your's ended up in spam
filter...  :-(

On Wed, Jan 26, 2011 at 01:56, Moreland, Kenneth kmo...@sandia.gov wrote:
 Looking at the source code, I believe it is assumed that the paths you give
 for images are relative to the directory ADD_LATEX_DOCUMENT is called.  If
 you make it an absolute path, UseLATEX.cmake will look in the wrong
 directory for your images, find none, and do no conversions.  That would
 explain why you had to point to your source directory and why pdflatex did
 not work if your images are in eps format.

 In summary, it should work if you use this as for IMAGE_DIRS

 IMAGE_DIRS ../figures

 and your graphics paths should be preserved relative to the source:

 \graphicspath{../figures}

 Note, however, if you are trying to do an in-source build with the directory
 structure below, UseLATEX.cmake will probably do something screwy with the
 figures output directory (that is, place it in top-level/latex/figures since
 that is one level down from top-level/latex/figures).


Thank you for your help and yes, I did get it working using your
instructions above.  Guess I only tried combinations where I did one
thing in my LaTeX file and then the CMakeLists.txt file undid it -- so
I never got it correct!

The downside is that inside my latex source directory, there is a
copy of my figures in PDF format -- but I can live with that or just
use the safepdf option.  Thank you for updating the module and sorry
again for the delay in my reply -- must check my spam folder more
often...

Ray
___
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] cmake with LaTeX [UseLATEX.cmake]

[Raymond Wan]

Hi Ken,



On Fri, Jan 28, 2011 at 00:38, Moreland, Kenneth kmo...@sandia.gov wrote:
...
 Rather than have the ADD_LATEX_DOCUMENT in top-level/latex/CMakelists.txt,
 try putting it in top-level instead and making all of your file references
 to top-level.  After you build, the document structure should be something
 like this

 top-level/
   +latex/
 +latex/build/
   +latex/build/latex
   +latex/build/figures
   +figures/

 Or you could just forget the whole thing and just do an out-of-source build.


Ah, yes -- you're right; I didn't think of that.  I had figures/ one
directory up because something else at that level relies on it; I
guess not having it below the LaTeX source is a bit unconventional...

So far, the safepdf option seems to work.  If something happens to
my documents that makes that break, I'll give your suggestion a try.

Thank you for making the UseLatex.cmake module and for answering my
questions about it!  Of course, my problem is still very minor and
definitely a step up from managing the Makefile.  So, thanks a lot for
making it available!

Ray
___
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] cmake with LaTeX [UseLATEX.cmake]

[Raymond Wan]

Hi Daniel,

Thanks for the reply!


On Tue, Jan 25, 2011 at 16:15, Daniel Pfeifer dan...@pfeifer-mail.de wrote:
 Am Dienstag, den 25.01.2011, 15:41 +0900 schrieb Raymond Wan:
  Everything is fine except that pdflatex
 doesn't seem to work with images well on my system...  That's of
 course my system [or my :-) ] fault, though.

 Do you use the IMAGE_DIRS or IMAGES parameters? UseLATEX.cmake should
 then convert all images to the right format. Maybe check you imagemagick
 installation.


Actually, neither.  I couldn't get them to work and went to plan B.
:-) I have a directory structure like:

top-level/
  +latex/
+latex/build/
  +figures/

So, my figures are in figures/.  I thought this would do:

IMAGE_DIRS ${CMAKE_CURRENT_SOURCE_DIR}/../figures/

but it wasn't working for me  I also tried IMAGES and that didn't work
as well.  I didn't pursue this further as I got:

\graphicspath{{@CMAKE_CURRENT_SOURCE_DIR@/../figures/}}

in the source LaTeX file to work and all my figures are in EPS format
anyway.  I will take a look at my imagemagick installation; but it
might also be that the figures aren't being located.


 ... Is there something I can do
 in my CMakeLists.txt file to ensure that it is the default target (and
 not pdf or any of the others) when I type make.

 Sure, there is the DEFAULT_PDF option. Have a look at section '3.3
 Create a PDF by Default' in the manual.


Yes, I've enabled that but I don't think that allows me to choose the
pdf target over the safepdf target.  Or is there something I'm
missing with this option?

Thank you!

Ray
___
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] cmake with LaTeX [UseLATEX.cmake]

[Raymond Wan]

Hi Daniel,


On Tue, Jan 25, 2011 at 16:15, Daniel Pfeifer dan...@pfeifer-mail.de wrote:
 Am Dienstag, den 25.01.2011, 15:41 +0900 schrieb Raymond Wan:
 ... Is there something I can do
 in my CMakeLists.txt file to ensure that it is the default target (and
 not pdf or any of the others) when I type make.

 Sure, there is the DEFAULT_PDF option. Have a look at section '3.3
 Create a PDF by Default' in the manual.


Thank you again for your help.  I gathered my courage for the week :-)
and decided to look at the source.  Based on my limited knowledge of
cmake, it seems that DEFAULT_PDF favors the pdflatex route.  Which is
of course not unreasonable if you're unlike me and have a working
Imagemagick.  ;-)

I changed it a bit and added a DEFAULT_SAFEPDF option and it seems
to work.  I will ask the original author to see if this change is of
interest to him.  Thanks again for your reply -- it did lead me to the
right direction!

Ray
___
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] cmake with LaTeX [UseLATEX.cmake]

[Raymond Wan]

Hi all,

I'm not sure if many people have experience with UseLATEX.cmake
(http://www.cmake.org/Wiki/CMakeUserUseLATEX), but I have a question
which I guess is general.  Everything is fine except that pdflatex
doesn't seem to work with images well on my system...  That's of
course my system [or my :-) ] fault, though.

But in the PDF documentation, it says that multiple targets are created:

dvi
pdf
safepdf
...

and safepdf seems to work fine with me.  Is there something I can do
in my CMakeLists.txt file to ensure that it is the default target (and
not pdf or any of the others) when I type make.  I mean, without
making changes to UseLATEX.cmake (but since the file is in my own
directory, I could change it if I have to).

Basically, my CMakeLists.txt makes multiple files and I would rather
do just make than make file1_safepdf file2_safepdf file3_safepdf
to update all 3 PDF files.

Thank you!

Ray
___
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] CPack 101

[Raymond Wan]

Hi Mike and all,


On Thu, Dec 23, 2010 at 21:58, Mike McQuaid m...@mikemcquaid.com wrote:
 On 23 December 2010 12:43, David Cole david.c...@kitware.com wrote:
 I think the main problem is that you make it very hard for people to
 contribute. KDE and Homebrew (two other open-source projects I've
 written a lot of code for over the years) make this very easy.

 Kitware is great, you clearly write good code and have done a great
 job creating CMake and CPack. They are fantastic tools. However, I
 think until you are more encouraging of external developers you will
 struggle to make huge improvements to CMake.


As only a casual user of CMake, I'm hesitant to enter this kind of
thread, but a comment like the above is difficult to ignore.  :-)

IMHO, the comparison between KDE and CMake is a bit unfair.  KDE is
visible to many people, both developers and users, while CMake is
known by only developers.  Also, it is known that CMake is developed
by Kitware; this is quite different from KDE which relies on a very
large international community.  So, combining these two reasons, it is
not so surprising that the management of how KDE is developed is more
advanced.

Yes, they are both open-source, but two software can be both
open-source but still be run differently.  It isn't necessary for one
open-source software to be managed similar to another one.  And I
think (without knowing the actual numbers) that the code to KDE is
larger than CMake?

Personally, the help I've seen on this mailing list and in the mailing
list archives is great and while there may be room for improvement, I
guess it can happen in time.



 The mailing list is OK but most people don't want to sign up to a
 mailing list and receive lots of emails that have nothing to do with
 them. I'm only signed up because I want to try and get some patches
 merged and was told that I should discuss things here rather than the
 bugtracker.

 I hope I don't cause any offense here either. I'm passionate about
 CMake because I like the tool and want to make it better.


Someone else has talked about using Google on the archives.

An often ignored point is that thanks to Google, you can contribute
to the documentation just by writing a web page.  If it is useful and
gets linked by others, etc., then the right keywords will make your
web page appear on the first page of Google's results.  Some of the
help I've got on CMake, CPack, etc. are on non-cmake pages, actually.
Of course, if these pages are wrong, then the error propagates...  But
if it is useful, I guess Kitware developers will be happy to include
it in the Wiki at least?

Ray
___
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] Linking archives in a sibling directory

[Raymond Wan]

Hi Michael,

Thank you for the follow-up and sorry for my late response!  I
appreciate your suggestions as they basically summarize the problems
I've been having...


On Wed, Dec 8, 2010 at 21:25, Michael Hertling mhertl...@online.de wrote:
 Yes, absolutely, with such relations among executables and libraries,
 their source directories should be siblings instead of descendants, and
 the libraries' testing executables can be conveniently integrated using
 ADD_TEST() without interfering with the main executables. However, when
 your project grows and, hence, the number of source directories in the
 project's root increases, say 10+, you should consider to organize them
 further, e.g. like


For example, I've reached around 10 source directories when I posted
my first message to the mailing list a couple of weeks back.  I
probably should have thought how to organize everything when I first
started -- but at least I'm thinking about it now instead of much
later!


 or whichever organizational criteria apply best, so the root directory
 doesn't fill with countless source directories. Apart from that, there
 is no need to have the top-level CMakeLists.txt create the main{1,2,3}
 executables by itself; just add a CMakeLists.txt file in each of their
 source directories as you do for the libraries, and use

 ADD_SUBDIRECTORY(main1)
 ADD_SUBDIRECTORY(main2)
 ADD_SUBDIRECTORY(main3)

 at the top level to enable them. In this way, you've a CMakeLists.txt
 file in each of your project's source directories which does exactly
 what needs to be done there, and the whole project is covered by the
 top-level CMakeLists.txt with minimal assumptions w.r.t. the source
 directories.


I see.  That makes sense to me; thank you!


 IMO, there is no reason to configure with lower-level CMakeLists.txt
 files at first and switch to a top-level CMakeLists.txt later. Instead,
 start right away with one CMakeLists.txt file per source directory and
 one top-level CMakeLists.txt, and whenever a new source directory with
 its own CMakeLists.txt is added to your project, just add an according
 ADD_SUBDIRECTORY() at the top level, too. So, you will always have a
 clean and regular configurational setup without the need to bother
 with different starting points for configuring your project.


Ok -- thank you for this; I'll definitely take your advice!

Thank you for your suggestions; I realize my question wasn't directly
related to CMake syntax and more generally to how to use CMake
properly for a project of this size.  Thank you for taking the time to
explain it to me; hopefully it has benefited others as well!

Ray
___
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] Linking archives in a sibling directory

[Raymond Wan]

Hi Michael,

Thank you for your continued advice!


On Fri, Dec 3, 2010 at 19:13, Michael Hertling mhertl...@online.de wrote:
 On 12/02/2010 03:13 PM, Raymond Wan wrote:
 ADD_SUBDIRECTORY (dir-A)

 before

 ADD_SUBDIRECTORY (main)

 then main will be built correctly?

 Even this is not necessary if the only reference of main to dir-A is
 TARGET_LINK_LIBRARIES(... subprogA_ar) in main/CMakeLists.txt since
 TARGET_LINK_LIBARIES(), AFAIK, does a lazy evaluation of the targets'
 dependencies, i.e. they are evaluated when all CMakeLists.txt files
 have been processed and, hence, all dependencies are known. If you
 refer to subprogA_ar in another way, e.g. SET_TARGET_PROPERTIES(),
 then you will get an error if dir-A hasn't been configured yet.


I see; I am using just TARGET_LINK_LIBRARIES (), so that is good to
know that I don't need to worry about the ordering.  Thank you!


 ADD_SUBDIRECTORY(../dir-A ${CMAKE_CURRENT_BINARY_DIR}/dir-A)

 yet this kind of duplication should be an error at worse; unnecessary
 repetition at best?

 Each invocation of ADD_SUBDIRECTORY() for a source directory must be
 associated with an own binary directory, so the above-mentioned line
 would allow you to use both alternatives. However, when configuring
 the top-level CMakeLists.txt, you will get an error due to multiple
 definitions of the subprogA_ar target. In main/CMakeLists.txt, you
 might protect ADD_SUBDIRECTORY() against multiple invocations like

 IF(NOT TARGET subprogA_ar)
   ADD_SUBDIRECTORY(../dir-A ${CMAKE_CURRENT_BINARY_DIR}/dir-A)
 ENDIF()

 or

 IF(${CMAKE_CURRENT_SOURCE_DIR} STREQUAL ${CMAKE_SOURCE_DIR})
   ADD_SUBDIRECTORY(../dir-A ${CMAKE_CURRENT_BINARY_DIR}/dir-A)
 ENDIF()

 but this does not appear really appropriate to me.

 Nevertheless, I wonder why you want to build main by configuring its
 own source directory and alternatively via the top-level directory. If
 this is because you'd like to exclude some modules from building, you
 should handle such things in the top-level CMakeLists.txt, e.g. like:

 # Define options:
 OPTION(WITH_MAIN Build module main ON)
 OPTION(WITH_A Build module A ON)
 OPTION(WITH_B Build module B ON)

 # Handle dependencies:
 IF(WITH_MAIN)
    SET(WITH_A ON)
 ENDIF()

 # Enable modules:
 IF(WITH_B)
    ADD_SUBDIRECTORY(dir-B)
 ENDIF()
 IF(WITH_A)
    ADD_SUBDIRECTORY(dir-A)
 ENDIF()
 IF(WITH_MAIN)
    ADD_SUBDIRECTORY(main)
 ENDIF()

 So, you can conveniently enable/disable the modules on the command line
 or in the GUI, e.g. with cmake -DWITH_B=OFF path/to/top-level-dir
 if you don't want to build module B.

 As an alternative, you might consider to move dir-A to main/dir-A if
 dir-A is essentially a submodule of main, but referring to a sibling
 dir-A from main indicates that the latter is not sufficiently self-
 contained to be built on its own with a cmake path/to/main, so
 the modules' relationships should be handled by other means, IMO.


Hm, I see your point about why I'm providing support in a
top-level CMakeLists.txt and a lower level one.  Perhaps I've simply
confused myself and made things more complicated than it needs to be.
Basically, what I want to do is, given this directory structure:

myproj/
  +dirA/
  +dirB/
  +dirC/
  +main1/
  +main2/
  +main3/

my final goal is that several programs (i.e., executables) will be
made.  Let's say main1, main2, and main3.  The libraries dirA, ...,
dirD are used by them and can also depend on each other with maybe
even multiple levels of dependencies.  i.e.,

dirA -- dirB -- dirC

Any of these modules can be used by more than one program.  i.e.,

main1 -- dirA -- dirB -- dirC
main2 -- dirC

My idea is that the top level CMakeLists.txt can create main1, main2,
and main3.  The lower level CMakeLists.txt in dirA/, dirB/, and dirC/
have their own main () which I am using to test them -- obviously,
these main () functions are not linked into main1, main2, and main3.
I only need them for development.  I think organizing dirA/, dirB/,
and dirC/ within main1/, main2/, and main3/ isn't the way to go since
these libraries are used by multiple executables.

Perhaps I should create and use the low-level CMakeLists.txt and when
I am finished development, then create the top-level ones for just
main1, main2, and main3.  In a way, I will only need to support either
the top-level CMakeLists.txt or the lower level one and never both at
the same time.  I guess I am ahead of myself and did both now, which
is complicating things for me.

H, I need to give this a bit more thought -- any suggestions
welcome...  Thank you!

Ray
___
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] Linking archives in a sibling directory

[Raymond Wan]

Hi Michael,


On Thu, Dec 2, 2010 at 19:40, Michael Hertling mhertl...@online.de wrote:
 On 12/01/2010 06:03 PM, Raymond Wan wrote:
 Ah!  I see.  Then is it recommended that this top-level CMakeLists.txt
 have just these lines, or should I move the ADD_EXECUTABLE, etc. lines
 here as well?  Or is this really up to me and there isn't a
 suggested paradigm?

 Basically, IMO, a CMakeLists.txt with ADD_EXECUTABLE() et al. should be
 placed in the same directory as the related source files unless there's
 a reason not to do so; this makes for modularity and a well organized
 code base. The above-mentioned directory structure with its top-level
 CMakeLists.txt containing just ADD_SUBDIRECTORY() commands keeps the
 modules main, dir-A and dir-B separate with minimal interconnections.
 In the previous structure, e.g., main/CMakeLists.txt had to know that
 dir-A resides in ../dir-A; now, such information is concentrated in
 the top-level CMakeLists.txt, and the sole reference of main to dir-A
 is the target subprogA_ar. Due to CMake's capabilities to track the
 dependencies among targets, it doesn't matter where dir-A is placed
 within the project's source tree. So, in short, don't move the
 ADD_EXECUTABLE() etc. to the top-level CMakeLists.txt.


I see -- I did not realize this point you made about CMake's
dependency tracking abilities.  So, basically the only thing I need to
worry about is the order of the ADD_SUBDIRECTORY ()'s.  As long as I
put

ADD_SUBDIRECTORY (dir-A)

before

ADD_SUBDIRECTORY (main)

then main will be built correctly?

But, if I am not mistaken and following what you are saying, I can
only build main using the top-level CMakeLists.txt.  The lower
CMakeLists.txt in main/ does not know the location of dir-A.  The
only way for both to work is to have this in main/CMakeLists.txt:

ADD_SUBDIRECTORY(../dir-A ${CMAKE_CURRENT_BINARY_DIR}/dir-A)

yet this kind of duplication should be an error at worse; unnecessary
repetition at best?


 The top-level directory of non-trivial projects should not contain any
 source files, perhaps a config.h header or the like. Usually, there're
 enough things gathering in a project's root, e.g. READMEs, subdirs for
 documentation, resources or CMake stuff, a CMakeLists.txt file ;) etc.
 The sources, however, should be organized in their own subdirectories,
 so the top-level CMakeLists.txt typically contains ADD_SUBDIRECTORY()
 commands along with configurational stuff like setting up compiler
 flags, processing options or investigating the underlying system,
 but no ADD_EXECUTABLE() or the like.

 Of course, there're exceptions and probably strong different opinions.


I see!  Thank you for this!  I'll stick with standard practice for now
and leave the exceptions and stronger opposing opinions to people who
know more about CMake than me.  :-)

Thank you very much for the explanation!

Ray
___
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] Linking archives in a sibling directory

[Raymond Wan]

Hi Rolf,


On Thu, Dec 2, 2010 at 23:36, Rolf Eike Beer e...@sf-mail.de wrote:
 Let's say you have

 dirA, dirB, dirC

 dirA builds a lib
 dirB builds a lib that needs libA
 dirC builds a target that needs libA and libB

 Then you can't do


 libB/CMakeLists.txt
  ADD_SUBDIRECTORY(../dirA dira)

 libB/CMakeLists.txt
  ADD_SUBDIRECTORY(../dirA dira)
  ADD_SUBDIRECTORY(../dirB dirb)


 CMakeLists.txt

 ADD_SUBDIRECTORY(dirA)
 ADD_SUBDIRECTORY(dirB)
 ADD_SUBDIRECTORY(dirC)


Yes -- that's exactly what I was trying to say.  Thank you for the example!

I suppose the default behavior of ADD_SUBDIRECTORY is understandable
since it is meant to catch duplicate names.  By this I mean that maybe
its aim was to catch these problems when they are caused by human
error.


 since dirA is included twice. We have a module for that:

 function (Add_Subdirectory_Once SUBDIRECTORY)
...


Thank you for this!  I presume by We you mean you and your
organization?  That is, this function isn't in CMake.

I'll give it a try and see if it solves my problems.  Thank you all
for your explanations!

Ray
___
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] Linking archives in a sibling directory

[Raymond Wan]

Hi Michael,


On Thu, Dec 2, 2010 at 01:03, Michael Hertling mhertl...@online.de wrote:
 On 12/01/2010 08:18 AM, Raymond Wan wrote:
 Hi all,

 I'm having a problem understanding how I can link to an archive in
 another directory which is not a subdirectory. For example:

 myproj
   +-- main
     +-- CMakeLists.txt
     +-- source files for main program
   +-- dir-A
     +-- CMakeLists.txt
     +-- source files for sub-program A
   +-- dir-B
     +-- CmakeLists.txt
     +-- source files for sub-program B

 This error is caused by the fact that the directory dir-A is outside
 the main directory tree, so dir-A's binary directory would likewise
 be outside main's binary tree, and this is reasonably forbidden when
 configuring main. You might specify dir-A's binary directory in
 main/CMakeLists.txt explicitly, e.g.:

 ADD_SUBDIRECTORY(../dir-A ${CMAKE_CURRENT_BINARY_DIR}/dir-A)

 Hence, subprogA_ar will be built within the binary tree's dir-A.


Ah!  I see now.  I didn't realize I could prepend a path like that.  I
was trying to find some kind of ADD_DIRECTORY command which had this
restriction removed.  But then I realized if I'm looking for something
like that, there might be a bigger problem in terms of how I'm
organizing things...


 myproj
   +-- main
     +-- CMakeLists.txt
     +-- source files for main program
     +-- dir-A
       +-- source files for sub-program A
     +-- dir-B
       +-- source files for sub-program B


 Is this what I should have done??

 As an alternative, consider to add a CMakeLists.txt in myproj

 CMAKE_MINIMUM_REQUIRED(...)
 PROJECT(myproj)
 ADD_SUBDIRECTORY(dir-A)
 ADD_SUBDIRECTORY(dir-B)
 ADD_SUBDIRECTORY(main)

 and subsequently, configure this directory instead of main.


Ah!  I see.  Then is it recommended that this top-level CMakeLists.txt
have just these lines, or should I move the ADD_EXECUTABLE, etc. lines
here as well?  Or is this really up to me and there isn't a
suggested paradigm?

I guess I chose my first directory layout because the source in a
directory (i.e., dir-A) can be several dependencies down and it can
even be used by two targets in two different directories.  So, I
figured that keeping them all at the same directory level would be
best.  But it seems what you're suggesting here seems better -- never
thought of it; the myproj directory has no files in it...just
directories right now...

Thank you for your advice!

Ray
___
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] Linking archives in a sibling directory

[Raymond Wan]

Hi all,

I'm having a problem understanding how I can link to an archive in
another directory which is not a subdirectory. For example:

myproj
  +-- main
+-- CMakeLists.txt
+-- source files for main program
  +-- dir-A
+-- CMakeLists.txt
+-- source files for sub-program A
  +-- dir-B
+-- CmakeLists.txt
+-- source files for sub-program B


Basically, I would like to make a larger project (main) and I'm
building and testing each of its components separately.

Right now, the main's CMakeLists.txt looks something like this:


INCLUDE_DIRECTORIES (../dir-A)
SUBDIRS (../dir-A)
ADD_EXECUTABLE (main ${MAIN_SRCS})
TARGET_LINK_LIBRARIES (main subprogA_ar)


which works fine so far (the CMakeLists.txt in dir-A generates the
archive subprogA_ar).

However, I just found out that SUBDIRS is deprecated and so, replaced
it with ADD_SUBDIRECTORY.  That's when I got an error about dir-A
not being a subdirectory.  Obviously, I was not using SUBDIRS before
as it was intended...  :-)

I've also tried adding dir-A as a LINK_DIRECTORIES with no success.
It is unable to find subprogA_ar.

I'm not sure if it is possible, but ideally, when I run make in
main/, I would like it to rebuild the targets in dir-A (including
the archive) and link that in.

I'm also open to the possibility that I got the above organization all
wrong and should have only one large CMakeLists.txt in a directory
structure like this:


myproj
  +-- main
+-- CMakeLists.txt
+-- source files for main program
+-- dir-A
  +-- source files for sub-program A
+-- dir-B
  +-- source files for sub-program B


Is this what I should have done??

Thank you!

Ray
___
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] makefile to CMakeLists.txt, possible?

[Raymond Wan]

Hi Andreas,

Thanks for the reply and the two points that you raised.

Yes, make -j is what I was thinking of.  It just didn't occur to me
that it would be make's job; thought separating compilation into
multiple processes has be done at the point the Makefile is
created...guess I was wrong...

Thanks and sorry for the delay; was away from e-mail for a few days
and I've noticed the thread has gone away already...  Just wanted to
say thanks!

Ray


On Thu, Sep 2, 2010 at 23:44, Diablo 666 thediablo...@hotmail.de wrote:
 Hi,

 For example, when you add a C++ source file,
 you'll need to run cmake and then make.

 make will automatically re-run cmake, if the cmake files have changed.
 I guess, there will be some IDEs automatically generating cmake files in the
 future.

 generate n Makefiles so that each CPU is responsible for just their parts

 you might want to try make -j. I guess, this is exactly what you are
 searching for.

 Best regards,
 Andreas
___
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] makefile to CMakeLists.txt, possible?

[Raymond Wan]

Hi Chiheng,


On Thu, Sep 2, 2010 at 16:15, Chiheng Xu chiheng...@gmail.com wrote:
 CMake is a very great tool.    But its drawback is also obvious.    It
 will consume large amount of time to generate Makefiles every time you
 want to build,  especially for ultra large projects.   Building can be
 parallelized, but the CMaking, like runing configure scripts, can't be
 parallelized.   So, the caching of Makefiles seems benefitial  for
 current and future mutil-cores systems.

 Normal developers seldomly touch CMakeLists.txt.  So,  in very rare
 condition, you need to regenerate the Makefiles.


As someone who just started using CMake (quite literally a few weeks
ago), I'm somewhat interested in your arguments.  Personally, I don't
see many drawbacks and I must be missing something if they are
obvious.

It is true that while developing software, using CMake requires an
extra step.  For example, when you add a C++ source file, you'll need
to run cmake and then make.  But after development, having your
software being usable across multiple platforms seems to be worth it.
If later on, you want to add a file, you don't have to modify the
Linux Makefile, the Mac Makefile, and the Windows Makefile.  IMHO,
CMake saves the time of the developers.

After many years of writing Makefile files by hand, Autotools seemed
like moving 3 steps forward and 2 steps back.  CMake seems to be a big
improvement.  But CMake makes Makefiles and if you don't like it, you
can always stick with just Makefiles.  When you get tired of that,
then you'll be glad that both Autotools and CMake are available
options for you...

Ray

PS:  Your example of parallel compilation doesn't take into account
that only the files that change need to be recompiled.  And then when
the executable is to be re-linked, the object files have to be placed
on the same disk, etc.  I don't know if CMake supports parallel
compilation (i.e., for n processors, generate n Makefiles so that each
CPU is responsible for just their parts), but that would be cool...
:-)
___
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] Conditional compiling [i.e. OpenMP]

[Raymond Wan]

Hi all,

I'm still quite new to cmake and am trying to do something I use to do
with autotools (took me ages to figure that out :-) ).  I guess what
I'm trying to do is not specific to OpenMP, though.

In my C++ code, I'd like to add:

#if HAVE_OPENMP
#include omp.h
#endif

and have this check around other OpenMP-related lines.  I came across
this article on How to write platform checks:
http://www.cmake.org/Wiki/CMake:How_To_Write_Platform_Checks .

So, I tried to do something similar (but with SET since the article
gave an example on checking for header files which I don't need to
do), and it doesn't seem to work.  For example, I have this:

#
FIND_PACKAGE (OpenMP)

if (OPENMP_FOUND)
  SET (HAVE_OPENMP 1)
  SET (CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} ${OpenMP_CXX_FLAGS})
endif()
#

and then created a config.hpp.in which had this:

#cmakedefine HAVE_OPENMP 1

config.hpp gets generated fine, but it ends up having this:

/* #undef HAVE_OPENMP */

I can confirm that OpenMP is being detected because I can see the
various values being defined in CMakeCache.txt.  HAVE_OPENMP is not in
this file, though (it should, I presume?).

I think SET (HAVE_OPENMP 1) is wrong, but I don't know what should
it be.  If it is correct, do I need to initialize it with SET
(HAVE_OPENMP 0) before?

Thank you!

Ray
___
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] Conditional compiling [i.e. OpenMP] -- solved!

[Raymond Wan]

Hi Ryan and Eric,

Thank you both for your replies!


On Tue, Aug 31, 2010 at 20:10, Ryan Pavlik rpav...@iastate.edu wrote:
  On 8/31/10 3:40 AM, Raymond Wan wrote:
 I think SET (HAVE_OPENMP 1) is wrong, but I don't know what should
 it be.  If it is correct, do I need to initialize it with SET
 (HAVE_OPENMP 0) before?

 Thank you!

 Ray

 My guess is that you're generating your config.h before (earlier in the
 file) you are setting the HAVE_OPENMP variable, because everything else
 you've mentioned sounds OK.


*argh*  I feel so silly now -- yes, that was exactly my problem!  I
didn't realize that the location of CONFIGURE_FILE was important -- I
naively thought that the actual generation of the configuration file
is done after processing the entire CMakeLists.txt.  i.e., the file
lists the things that need to be done and nothing is done until after
the file is read.  I was wrong and why I thought that is odd since
that's how scripts work...

I guess I was too focused on how I was using the SET command; thinking
that I must have got that wrong...

Thank you both for your help!

Ray
___
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] Conditional compiling [i.e. OpenMP]

[Raymond Wan]

Hi Eric,


On Tue, Aug 31, 2010 at 20:59, Eric Noulard eric.noul...@gmail.com wrote:
 2010/8/31 Raymond Wan r@aist.go.jp:
 /* #undef HAVE_OPENMP */
 I can confirm that OpenMP is being detected because I can see the
 various values being defined in CMakeCache.txt.  HAVE_OPENMP is not in
 this file, though (it should, I presume?).

 HAVE_OPENMP is not in CMakeCache.txt because you did not defined
 it to be a cache var.

 However, I don't think HAVE_OPENMP have to be a cache var for this to work.


I see.  I didn't realize that I had to make variables into cache-able
and that they aren't be default.  I'll read more about it; I thought
it was by default and that I could use CMakeCache.txt to see where the
problem was.


 We are missing your CONFIGURE_FILE statement how does it look like?
 May be you can try a simple test:

 set(OPENMP_FOUND 1)

 if (OPENMP_FOUND)
   SET (HAVE_OPENMP 1)
   SET (CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} ${OpenMP_CXX_FLAGS})
 endif()

 configure_file(${CMAKE_CURRENT_SOURCE_DIR}/config.hpp.in
                            ${CMAKE_CURRENT_BINARY_DIR}/config.hpp)


Thank you for this!  As I just said in my previous message to the
list, that was exactly my problem.  I didn't realize the importance of
the location of configure_file and placed it at the top of
CMakeLists.txt.  In hindsight, that was such a terrible idea!

I've been looking at the cmake docs for individual commands and
somewhat ignoring their order (since some, like the compiler flags,
just append to what it is so far).  This thinking got me in
trouble...and I'll be careful about this -- thank you!

Ray
___
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