Robert Dailey | 1 Dec 01:42 2008
Picon

Re: Invoking "make" with CMake scripts?

On Sat, Nov 29, 2008 at 3:52 PM, Mike Arthur <mike-CaIw7823lSddFdQDRdrngQ@public.gmane.org> wrote:

The typical way this is handled in both CMake and generally is that you rely
on the builder of your sourcecode to have the dependencies already installed
and then use Find* modules to determine if the libraries are installed and
either block the build or adjust the options depending on what the user has
installed. Having your build system build the other libraries or (even worse)
having copies of them in your source tree is not a good idea as you need to
keep up to date with their buildsystem and also apply any security fixes or
whatever to your local version of the application.

I generally like keeping libraries in version control because it makes it convenient to start working from a fresh checkout. This is really only an issue with Windows, since most linux distributions have a package management system that makes it trivial to install third party library dependencies. On Windows, it's quite a pain to visit various websites and downloads the limitless number of dependencies. If you flatten the dependency tree, you'll probably end up downloading 10 or more different libraries, each of which is pretty difficult to build on Windows. A developer on windows could be looking at a couple of hours before the project is ready to compile. Am I looking at this the wrong way, or is this just the reality all Windows developers have to face?

Thanks again for all the help guys.
_______________________________________________
CMake mailing list
CMake@...
http://www.cmake.org/mailman/listinfo/cmake
Michael Jackson | 1 Dec 03:08 2008
Picon

Re: CMakeEd Eclipse Plugin has another Release Candidate Ready.


On Nov 30, 2008, at 3:10 PM, Eric Noulard wrote:

> 2008/11/30 Michael Jackson <mike.jackson@...>:
>> I have posted another Release Candidate for the CMakeEd Eclipse  
>> Plugin. You
>> can download it from <http://cmakeed.sourceforge.net>.
>>
>> Fixed in this release is better indexing of user defined variables  
>> and
>> updated documentation generated from CMake itself.
>
> Just updated;
> It is just fine however since you parsed the doc from CMake itself
> is it possible to have the full doc for a CMake command and not the
> "small doc summary"?
>
> When I ctrl-space I do have completion + small doc
> but I would like to see full doc just like the one
> shown with
>
> cmake --help-command
>
> Do I miss something ?
> Is it already possible?
> If not is hard to do?
>
> However thank you for this colorful editor.
> -- 
> Erk

If you use the built in help from Eclipse you can browse and search  
the complete CMake documentation as generated from CMake itself. If  
you bring up the Eclipse Help there should be a new section for CMake.

If this is not what you want then file a feature request at the  
CMakeEd sourceforge site.

http://sourceforge.net/tracker/?group_id=193949

Thanks for the feedback.
_________________________________________________________
Mike Jackson                  mike.jackson@...
BlueQuartz Software                    www.bluequartz.net
Principal Software Engineer                  Dayton, Ohio
Eric Noulard | 1 Dec 09:04 2008
Picon

Re: CMakeEd Eclipse Plugin has another Release Candidate Ready.

2008/12/1 Michael Jackson <mike.jackson@...>:
>
> If you use the built in help from Eclipse you can browse and search the
> complete CMake documentation as generated from CMake itself. If you bring up
> the Eclipse Help there should be a new section for CMake.

Yes that's right and I missed that.
In fact I almost never use the eclipse help system because its an
extra window  :=)

I'd rather have the full help text when requesting completion.

> If this is not what you want then file a feature request at the CMakeEd
> sourceforge site.
>
> http://sourceforge.net/tracker/?group_id=193949

I filed a feature request
https://sourceforge.net/tracker/index.php?func=detail&aid=2369701&group_id=193949&atid=947466

however it may be redundant with the eclipse help system.

--

-- 
Erk
Micha Renner | 1 Dec 12:04 2008
Picon

IMPORTED_LOCATION

Hello, 

I have two questions for the listening below.

1. Out-commenting the line #4
results in a linker error LINK : fatal error LNK1104: File
"_sLib-NOTFOUND.obj" can't be opened"

What is the purpose of this command (line #4)?

2. If line #4 is active. An inspection of the project properties (link
-> command line) shows in the implib-section the following result:
/IMPLIB:"C:\WORK-C\ArchiveCMake\CMakeListsNeu\BuildDLL-2\TestDLL\CMake
\Debug\TestDll2.lib" /ERRORREPORT:PROMPT kernel32.lib user32.lib
gdi32.lib winspool.lib shell32.lib ole32.lib 
oleaut32.lib uuid.lib comdlg32.lib advapi32.lib  
\WORK-C\ArchiveCMake\CMakeListsNeu\BuildDLL-2\DLL\CMake\Debug\SLib.lib

For what reason is there a TestDll2.lib?

Michael

Start of listening ----------------------------------------------------

1:PROJECT(TestDLL)

2:CMAKE_MINIMUM_REQUIRED(VERSION 2.6)

3:ADD_LIBRARY(_sLib SHARED IMPORTED)
4:SET_PROPERTY(TARGET _sLib PROPERTY IMPORTED_LOCATION /Path/SLib.dll) 
5:SET_PROPERTY(TARGET _sLib PROPERTY IMPORTED_IMPLIB /Path/SLib.lib)

6:INCLUDE_DIRECTORIES(/myIncludeDir)

7:SET(_src MRTestC.c)  
8:ADD_EXECUTABLE(TestDll2 ${_src})
9:TARGET_LINK_LIBRARIES(TestDll2 _sLib)
Bill Hoffman | 1 Dec 14:09 2008

Re: IMPORTED_LOCATION

Micha Renner wrote:
> Hello, 
> 
> I have two questions for the listening below.
> 
> 1. Out-commenting the line #4
> results in a linker error LINK : fatal error LNK1104: File
> "_sLib-NOTFOUND.obj" can't be opened"
> 
> What is the purpose of this command (line #4)?
> 
The imported targets are new.  Looks like a small glitch...

Here are the docs:
http://www.cmake.org/cmake/help/cmake2.6docs.html#prop_tgt:IMPORTED_LOCATION
http://www.cmake.org/cmake/help/cmake2.6docs.html#prop_tgt:IMPORTED_IMPLIB

Looks like IMPORTED_LOCATION should be ignored if IMPORTED_IMPLIB is found.

> 2. If line #4 is active. An inspection of the project properties (link
> -> command line) shows in the implib-section the following result:
> /IMPLIB:"C:\WORK-C\ArchiveCMake\CMakeListsNeu\BuildDLL-2\TestDLL\CMake
> \Debug\TestDll2.lib" /ERRORREPORT:PROMPT kernel32.lib user32.lib
> gdi32.lib winspool.lib shell32.lib ole32.lib 
> oleaut32.lib uuid.lib comdlg32.lib advapi32.lib  
> \WORK-C\ArchiveCMake\CMakeListsNeu\BuildDLL-2\DLL\CMake\Debug\SLib.lib
> 
> For what reason is there a TestDll2.lib?

You can export symbols from an executable on windows.  So, CMake will 
create the import library file.

> 
> Michael
> 
> Start of listening ----------------------------------------------------
> 
> 1:PROJECT(TestDLL)
> 
> 2:CMAKE_MINIMUM_REQUIRED(VERSION 2.6)
>  
> 3:ADD_LIBRARY(_sLib SHARED IMPORTED)
> 4:SET_PROPERTY(TARGET _sLib PROPERTY IMPORTED_LOCATION /Path/SLib.dll) 
> 5:SET_PROPERTY(TARGET _sLib PROPERTY IMPORTED_IMPLIB /Path/SLib.lib)
> 
> 6:INCLUDE_DIRECTORIES(/myIncludeDir)
> 
> 7:SET(_src MRTestC.c)  
> 8:ADD_EXECUTABLE(TestDll2 ${_src})
> 9:TARGET_LINK_LIBRARIES(TestDll2 _sLib)
> 
Johannes Dohmen | 1 Dec 14:38 2008
Picon

Future of debian package generator?

Hi list,

ok, my question is already in the subject.

After some tests I like the idea of packaging debs with cmake [0] very 
much, but I would like to know how the future plans for this feature are.

I will describe why I'm uncertain of it's future:
AFAIK Mathieu Malaterre implemented the packaging of debs for cmake 
(thank you very much!) and was criticized by the debian developers for 
not doing it the "right" way.
Mathieu tried to improve the packaging for getting more accordance by 
the debian developers. All this can be read in the debian-devel mailing 
list.
The last mail from Mathieu at this list with reference to cmake was this:
http://www.mail-archive.com/debian-devel-0aAXYlwwYIJuHlm7Suoebg <at> public.gmane.org/msg261679.html

I did not find anything regards the future of the debian packaging on 
the cmake website or the mailing-list so far...

So will there be a deb-packer in cmake 2.8? Is there any hope to get the 
blessing of the debian developers for it?

Greetings from Germany
Johannes

[0]: 
http://www.cmake.org/Wiki/CMake:CPackPackageGenerators#DEB_.28UNIX_only.29
Micha Renner | 1 Dec 15:07 2008
Picon

Re: IMPORTED_LOCATION

Am Montag, den 01.12.2008, 08:09 -0500 schrieb Bill Hoffman:
> Micha Renner wrote:
> > Hello, 
> > 
> > I have two questions for the listening below.
> > 
> > 1. Out-commenting the line #4
> > results in a linker error LINK : fatal error LNK1104: File
> > "_sLib-NOTFOUND.obj" can't be opened"
> > 
> > What is the purpose of this command (line #4)?
> > 
> The imported targets are new.  Looks like a small glitch...

This doesn't answer my question. 
Why is it helpful to know the location of the Windows-DLL during the
build-process? 
I'm not an expert, but for me it makes only sense, if I want to use a
DLL, which is not located in an execution-directory of the OS. 
This would a nice feature.

> 
> Here are the docs:
> http://www.cmake.org/cmake/help/cmake2.6docs.html#prop_tgt:IMPORTED_LOCATION
> http://www.cmake.org/cmake/help/cmake2.6docs.html#prop_tgt:IMPORTED_IMPLIB

No, without http://www.cmake.org/Wiki/CMake_2.6_Notes
you are helpless.

> 
> Looks like IMPORTED_LOCATION should be ignored if IMPORTED_IMPLIB is found.

That is not the case, okay. 

> 
> > 2. If line #4 is active. An inspection of the project properties (link
> > -> command line) shows in the implib-section the following result:
> > /IMPLIB:"C:\WORK-C\ArchiveCMake\CMakeListsNeu\BuildDLL-2\TestDLL\CMake
> > \Debug\TestDll2.lib" /ERRORREPORT:PROMPT kernel32.lib user32.lib
> > gdi32.lib winspool.lib shell32.lib ole32.lib 
> > oleaut32.lib uuid.lib comdlg32.lib advapi32.lib  
> > \WORK-C\ArchiveCMake\CMakeListsNeu\BuildDLL-2\DLL\CMake\Debug\SLib.lib
> > 
> > For what reason is there a TestDll2.lib?
> 
> You can export symbols from an executable on windows.  So, CMake will 
> create the import library file.

Who needs this?

Anyway, thanks for help.

Michael

> 
> 
> > 
> > Michael
> > 
> > Start of listening ----------------------------------------------------
> > 
> > 1:PROJECT(TestDLL)
> > 
> > 2:CMAKE_MINIMUM_REQUIRED(VERSION 2.6)
> >  
> > 3:ADD_LIBRARY(_sLib SHARED IMPORTED)
> > 4:SET_PROPERTY(TARGET _sLib PROPERTY IMPORTED_LOCATION /Path/SLib.dll) 
> > 5:SET_PROPERTY(TARGET _sLib PROPERTY IMPORTED_IMPLIB /Path/SLib.lib)
> > 
> > 6:INCLUDE_DIRECTORIES(/myIncludeDir)
> > 
> > 7:SET(_src MRTestC.c)  
> > 8:ADD_EXECUTABLE(TestDll2 ${_src})
> > 9:TARGET_LINK_LIBRARIES(TestDll2 _sLib)
> > 
Maik Beckmann | 1 Dec 15:58 2008

Re: IMPORTED_LOCATION

Am Montag, 1. Dezember 2008 schrieb Micha Renner:
> Why is it helpful to know the location of the Windows-DLL during the
> build-process?

mingw's linker ignores the import .lib and takes .dll directly.
David.Karr | 1 Dec 16:50 2008

Automatically listing source files with GLOB (Re: How to make FILE() append to the list of files?)

>>> find . -name "*.c" > source_files.txt
>>> edit source_files.txt and put that list of files exiplicitly into a
>>> CMakeLists.txt file.
>>>
>>> file(GLOB is a bad way to get source lists for CMake.   CMake has 
>>> no way of knowing when new files have been put in the directory.
>>
>> But unless I am missing a fundamental feature somewhere, GLOB still
>> seems to be the better alternative. While it may not intrinsically
>> know when new files have appeared on the filesystem, the programmer
>> can simply re-run the CMake command to get an updated project with
>> the newly added source files without editing the CMakeLists.txt
>> file directly.
>
>Yes but when he add a source file, he won't necessarily remember he
>MUST rerun CMake manually [...]
>
>Whereas with hard-written sources files in CMakeLists.txt, the user
>will get accustomed to "simple" CMakeList.txt editing [...]
>
>[...]
>
>It usually looks like a better alternative (but I may be wrong) when
>you are in the process of converting several project to CMake and you
>end-up writing a lot of boring CMakeLists.txt in the startup process
>:=)

Actually, when I was last faced with this task I decided the easier
alternative for me was to cut and paste a lot of boring directory
listings into my CMakeLists.txt files.  (This was in a much earlier
version of CMake, and IIRC there was some problem with file globbing
back then that was fixed soon afterward.)

The reason for my choice at that time was user acceptance.  I had a
brief window of opportunity to introduce a new build system based on
CMake, which did not give me time to train all the developers in CMake
before deploying it.  One of the first objections I received was that
it was "much harder" to add, remove, or rename source files in CMake
than via the Visual Studio interface.  So I made it a "pushbutton"
process: the developer just had to run a script named something like
MakeWorkspace.bat.

Besides the project developers themselves, I also had users who needed
to be able just to build the project without doing any development on
it.  I actually got in trouble with those users on account of the one
directory where I had listed the source files individually instead
of "globbing" them.  The problem was solved when we "globbed" that
directory too.

I've had second thoughts about all this, for example the other day
when someone forgot to tell a developer newly introduced to this
project that he needed to run the script after adding source
files--that is, we forgot until he came to me asking about his link
errors.  On the other hand, it takes very little time for people to
develop new habits that tell them when to re-run the script.  I'm
probably going to change some things about the build procedure sooner
or later, but I don't know if or when this will be one of them.

The conclusion for me is that when I write a CMakeLists.txt file for a
personal project, I never "glob" the files; but the build design of a
long-running project needs to account for who is working on it and
what procedures will work best for them.  That may imply listing the
files explicitly, but it could conceivably imply "globbing" them.

David Karr
Hendrik Sattler | 1 Dec 16:54 2008
Picon

Re: Invoking "make" with CMake scripts?

Robert Dailey schrieb:
> I generally like keeping libraries in version control because it makes it
> convenient to start working from a fresh checkout. This is really only an
> issue with Windows, since most linux distributions have a package management
> system that makes it trivial to install third party library dependencies. On
> Windows, it's quite a pain to visit various websites and downloads the
> limitless number of dependencies. If you flatten the dependency tree, you'll
> probably end up downloading 10 or more different libraries, each of which is
> pretty difficult to build on Windows. A developer on windows could be
> looking at a couple of hours before the project is ready to compile. Am I
> looking at this the wrong way, or is this just the reality all Windows
> developers have to face?

I would keep this separate. You only need to setup the environment once.
This is a completely different task then the actual development.
Additionally: why not provide one package for your developers that they
only have to unpack to some dir and can start? Why should they all
compile the same thing? This way, only one has to go through the trouble
of porting an compiling the stuff.
That is roughly equal to installing your distribution's packages.

HS

Gmane