Cross-platform open-source make system ()

headers Robert Dailey | 1 Dec 2008 01:42

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

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

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

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)

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)
> 

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

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)
> > 

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.

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

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

Mon	Tue	Wed	Thu	Fri	Sat	Sun

1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28
29	30	31

208	May 2013
426	April 2013
425	March 2013
356	February 2013
312	January 2013
197	December 2012
288	November 2012
349	October 2012
394	September 2012
409	August 2012
331	July 2012
531	June 2012
455	May 2012
316	April 2012
385	March 2012
459	February 2012
579	January 2012
489	December 2011
721	November 2011
583	October 2011
452	September 2011
405	August 2011
428	July 2011
584	June 2011
496	May 2011
424	April 2011
581	March 2011
694	February 2011
745	January 2011
529	December 2010
591	November 2010
579	October 2010
642	September 2010
613	August 2010
797	July 2010
586	June 2010
542	May 2010
457	April 2010
747	March 2010
544	February 2010
640	January 2010
651	December 2009
644	November 2009
600	October 2009
648	September 2009
591	August 2009
563	July 2009
739	June 2009
618	May 2009
732	April 2009
978	March 2009
620	February 2009
516	January 2009
575	December 2008
696	November 2008
584	October 2008
632	September 2008
576	August 2008
647	July 2008
451	June 2008
705	May 2008
538	April 2008
671	March 2008
620	February 2008
665	January 2008
789	December 2007
824	November 2007
639	October 2007
552	September 2007
579	August 2007
610	July 2007
525	June 2007
536	May 2007
370	April 2007
411	March 2007
267	February 2007
363	January 2007
293	December 2006
355	November 2006
416	October 2006
423	September 2006
512	August 2006
484	July 2006
513	June 2006
400	May 2006
243	April 2006
307	March 2006
330	February 2006
270	January 2006

Re: Invoking "make" with CMake scripts?

Re: CMakeEd Eclipse Plugin has another Release Candidate Ready.

Re: CMakeEd Eclipse Plugin has another Release Candidate Ready.

IMPORTED_LOCATION

Re: IMPORTED_LOCATION

Future of debian package generator?

Re: IMPORTED_LOCATION

Re: IMPORTED_LOCATION

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

Re: Invoking "make" with CMake scripts?