Re: [cmake-developers] Obtaining header file dependencies of a source file manually

[Michael Wild]

On Sun, Nov 29, 2015, 10:47 Dan Liew  wrote:

Hi,

# TL;DR

I need a way of determining the header file dependencies of a source
file and inform CMake about them. CMake doesn't do this automatically
because I'm using custom commands for the compilation step so CMake
doesn't do it's usual magic of automatically inferring source file
header dependencies. This is because this part of the compilation step
requires a separate C++ compiler (completely independent from the one
that CMake detects at configure time).

Is there a way of doing this that will also regenerate the
dependencies if the source file changes?

# Long version

A C++ project that I work on [1] is (amongst other things) a compiler.
In order to compile applications it needs to link in a supporting
runtime that is compiled to LLVM bitcode which is linked into the
applications it compiles.

The supporting runtime is written in C++ and compiled with Clang. The
compilation of the runtime is currently achieved using
``add_custom_command()`` and so I am not using CMake's in built
support for detecting header file dependencies. The reason for doing
it this way is because the LLVM bitcode compiler (i.e. Clang) **is
not** the same compiler as the host C++ compiler for the project. For
example the host code might be built with MSVC but the supporting
runtime is **always** built with Clang.

To see this concretely take a look at [2].

The build works correctly if you build from a clean build directory.
It does not work correctly if you perform a rebuild and change one of
the header files that the supporting runtime depends on. This is
because CMake doesn't know that the runtime source files depend on the
header files and so doesn't rebuild the relevant source files.

I can obviously tell CMake about these manually (adding more entries
under ``DEPENDS`` in the ``add_custom_command()`` invocation) but this
is very cumbersome.

What I really need is a way to

* Automatically infer the dependencies of a source file and tell CMake
about them
* Have the dependencies automatically regenerated if the source file
changes (someone could add or remove a header file include).

In a simple Makefile build system this typically achieved by doing
something like this:

```
all:: $(SRCS:.cpp:.o)

SRCS := foo.cpp bar.cpp

# Include SRC file dependencies generated by the compiler if they exist
-include $(SRCs:.cpp=.d)

%.o : %.cpp
  $(CXX) -c $< -o $@ -MP -MMD -MF $*.d
```

Note the ``-M*`` flags get the compiler when it runs to generate
additional makefile rules that will get included next time a build
happens.

I don't really know how to do the same thing with CMake. One idea is
at configure time invoke Clang with the ``-MP -MMD -MF`` flags on each
runtime source file, extract the dependencies then pass them to
``DEPENDS`` in ``add_custom_command()``. If I wanted the dependencies
regenerated if the runtime source file changes then I would need to
somehow get CMake to reconfigure every time this happens.

I don't like this idea very much due to

* Having to invoke Clang manually to determine the dependencies. CMake
already knows how to determine source file dependencies, but this
functionality (AFAIK) isn't exposed to me.

* Reconfiguring every time one of the runtime source file changes is
annoying (configuring can be slow sometimes).

Does anyone have any other ideas? CMake obviously knows how to do all
this stuff already for source files being compiled for the detected
host C++ compiler, I just don't know how to get at this logic for
source files that need to be built with a second independent C++
compiler.

[1] https://github.com/halide/Halide
[2] https://github.com/halide/Halide/blob/master/src/CMakeLists.txt#L140

Thanks,
Dan.



Hi Dan,

Not going into detail as I'm typing on the phone, but this really sounds
like a case where a "SuperBuild" (
http://www.kitware.com/media/html/BuildingExternalProjectsWithCMake2.8.html)
can help you to simplify things a lot.

Michael
-- 

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

Re: [cmake-developers] Obtaining header file dependencies of a source file manually

[Michael Wild]

On Mon, Nov 30, 2015 at 7:01 PM, Dan Liew  wrote:
> Hi Michael,
>
>> Not going into detail as I'm typing on the phone, but this really sounds
>> like a case where a "SuperBuild"
>> (http://www.kitware.com/media/html/BuildingExternalProjectsWithCMake2.8.html)
>> can help you to simplify things a lot.
>
> Thanks for the suggestion but this certainly is not a case where a
> "SuperBuild" would help. CMake does not know how to configure a
> compiler that can produce LLVM Bitcode so using a "SuperBuild" is not
> going to help.
>
> Dan.


Hi Dan

I fail to see why that should not work. Producing LLVM bitcode from
C++ with Clang is just adding -emit-llvm flag, right? So, why can't
the SuperBuild configure the child build to use Clang and this flag?
And Bob's your uncle...

Michael
-- 

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

Re: [cmake-developers] git branches and cmake build trees

[Michael Wild]

On 9. Apr, 2010, at 21:30 , Alexander Neundorf wrote:

> Hi,
> 
> what is a good way to handle git branches and cmake build trees ?
> 
> With cvs/svn, I check out the branches I want into different source 
> directories, and then create build directories. Each build directory is tied 
> to a source directory, which is via CVS/svn tied to a branch.
> 
> How do I handle this with git ?
> If I understand correctly, the idea with git is to have 1 cloned repository 
> locally, and then create all the branches I need in this repository, and then 
> switch between the branches while staying in the same source directory and 
> just use git to switch the branch.
> But this means that if I want build trees for different branches, then they 
> all refer to the same source directory ? And I have to take care manually 
> that my (one) source directory is in the right branch currently ?
> 
> To have multiple source directories, I need multiple clones, right ? 
> Does this mean I have to clone the cmake repository once for each branch I 
> want ?
> How do you handle this ?
> 
> Alex

I forgot to mention another alternative I sometimes use: A single clone and 
multiple binary trees in combination with ccache to speed up unnecessary 
rebuilds after switching the branch. Using a shell-prompt which indicates the 
current branch (and its state) can be very useful too (e.g. zsh with vcs_info). 
E.g, currently my CMake prompt inside my CMake source tree looks like this:

mw...@nynaeve ~/Projects/cmake [git:master] ▶ 

Where the triangle changes color depending on whether the working tree is 
clean, has modifications or changes in changes in the index. Very, very useful 
(although, for very large projects sometimes slow).

Michael

___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] git branches and cmake build trees

[Michael Wild]

On 9. Apr, 2010, at 21:30 , Alexander Neundorf wrote:

> Hi,
> 
> what is a good way to handle git branches and cmake build trees ?
> 
> With cvs/svn, I check out the branches I want into different source 
> directories, and then create build directories. Each build directory is tied 
> to a source directory, which is via CVS/svn tied to a branch.
> 
> How do I handle this with git ?
> If I understand correctly, the idea with git is to have 1 cloned repository 
> locally, and then create all the branches I need in this repository, and then 
> switch between the branches while staying in the same source directory and 
> just use git to switch the branch.
> But this means that if I want build trees for different branches, then they 
> all refer to the same source directory ? And I have to take care manually 
> that my (one) source directory is in the right branch currently ?
> 
> To have multiple source directories, I need multiple clones, right ? 
> Does this mean I have to clone the cmake repository once for each branch I 
> want ?
> How do you handle this ?
> 
> Alex
> 

When you clone locally, git by default uses hard-links in in the newly created 
.git folder to save space. Also, there's the --shared option which causes it to 
actually share the local repository, but this can be dangerous, as is explained 
by "git help clone".

Personally, I simply "git clone" my local master repository for all the topic 
branches, push them to the master-repo and from there to the remote 
repositories.

HTH

Michael

___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Using push hook locally?

[Michael Wild]

> Hi All,
> 
> I have just pushed my first patch (since git move) to master git tree
> but I had to retry several times because of verifying hooks
> "error: hook declined to update refs/heads/master"
> (trailing whitespace, then comment line too long etc...)
> which is a good thing.
> 
> I wonder if I can use those hook locally for my local commit
> in order to avoid "discovering" those at push time?
> 
> Can one of you tell me how to do that?
>

Have look into your .git/hooks directory. If i remember correctly, there should 
be examples. Also, the log command has an option to check for whitespace errors.
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] git branches and cmake build trees

[Michael Wild]

On 11. Apr, 2010, at 19:00 , Alexander Neundorf wrote:

> Hi,
> 
> I think I have it working now.
> If somebody's interested, this is my clone on gitorious with branches for all 
> the things I'm wokring on currently:
> http://gitorious.org/~neundorf/cmake/neundorfs-cmake
> 
> Btw. are github and gitorious connected in some way ? Or how does it work 
> that 
> cmake and (some of) its clones appear on both ?
> 
> Alex


You just have to add another remote (git remote add) and push to all of your 
remotes (alternatively, you can just specify a URL in your push command).

BTW: When creating a tracking branch, you don't need to specify --track if the 
source reference is a remote branch (refer to the git-branch man page).

___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] CheckGNUCompilerVersion

[Michael Wild]

On 15. Apr, 2010, at 20:27 , Andreas Schneider wrote:

> Hi,
> 
> I've created a module to check for the gnu compiler version.
> 
> Example:  
>   
> 
> check_gnu_compiler_version("4.5.0" HAVE_GNU_COMPILER_VERSION) 
>   
> 
> 
> if (HAVE_GNU_COMPILER_VERSION)
>   
> 
>message(STATUS "GNU compiler version found")   
>   
> 
> endif (HAVE_GNU_COMPILER_VERSION)
> 
> I just wanted to get some opinions about it. Maybe someone has some idea for 
> improvement.
> 
> Cheers,
> 
>   -- andreas

Hi

I haven't tested it, but gave it a cursory glance. A few things:

- I'd name the second argument something with VAR in it to indicate that it's a 
variable name that is required. Also, you don't need to prefix variables inside 
a function, they are local in scope.

- First line in the function is missing a $ in the variable-reference. It 
should read:
  set(${_REQUIRED_VERSION_FOUND} FALSE PARENT_SCOPE)

- You don't have to check the compiler ID, there's the CMAKE_COMPILER_IS_GNUC 
variable.

- It would be nice if one could also check for the CXX compiler, perhaps as a 
first argument?

Michael
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] git doesn't let me push: bad whitespace at end of line

[Michael Wild]

On Sat, May 1, 2010 at 4:49 PM, Eric Noulard  wrote:

> 2010/5/1 Alexander Neundorf :
> > Hi,
> >
> > I tried to push a commit to master, but this failed because git
> complained
> > that the patch adds a trailing whitespace in one line.
> > So I removed this whitespace and committed this.
> > But git still doesn't push, I guess because the commit which adds the
> > whitespace is still there:
>
> I did have that trouble once.
>
> What I did was:
> 1) save a diff between offending commit and the current tree.
> git diff  HEAD > put-aside.patch
>
> 2) reset the clone to commit-ok
> git reset --hard commitid-ok
>
> 3) apply the put aside patch
>
> 4) fix the offending space
>
> 5) commit
>
> 6) push
>
> This may not be the most easiest way to do it but it worked for.
> I would be glad to know 'the definitive right way to do it'...
>
>
>
Much too complicated ;-)

If the offending commit is also HEAD, use "git commit --amend". If the
commit is older, you can use the following:

- "git rebase --interactive $OFFENDING_COMMIT^"
  (where $OFFENDING_COMMIT) is commit-ish for the offending commit
  (e.g. the hash or some other reference). Then, in the editor that pops up
  (likely vim or whatever is the default setting on your system), identify
the
  line with the offending commit and change the character in the first
column
  to "e". Save and quit.
- Now, git will take you to that commit and you can make the appropriate
changes
- "git commit --amend"
- "git rebase --continue".
- "git push"

If you already made a commit that fixes the issue, you can "squash" it with
the original, offending commit by using "git rebase --interactive",
rearranging the lines such that the commit with the fix is just below the
offending commit, and then change the first character in the line of the fix
to "s" (for squash). Save and quit and git will replay the history and
squash the fix into the offending commit (like "commit --amend"), giving you
the opportunity to modify the commit message.

Just make sure to not rebase beyond the last merge, that's asking for
trouble (unless, of course, you know exactly what you're doing and read "git
help rebase" very carefully)

HTH

Michael
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] git doesn't let me push: bad whitespace at end?of line

[Michael Wild]

On 2. May, 2010, at 15:22 , Bill Hoffman wrote:

> On 5/1/2010 2:39 PM, Alexander Neundorf wrote:
> 
>>> This might work for you as well:
>>> 
>>>   git rebase --whitespace=fix origin/master
>> 
>> Yes, worked :-)
>> 
> Git is great, once you get a handle on the 1000 or so different command line 
> options that are available... :)


I use the zsh which provides fabulous auto-completion of git commands. It even 
gives a short help string on commands and options. Further, I configured it to 
display a special prompt when I'm in a git tree, indicating the branch name and 
the state (clean, dirty, non-empty index) and whether a operation is in 
progress (e.g. during a merge or an interactive rebase).

Michael
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

[cmake-developers] Improve documentation of GetPrerequisites and BundleUtilities

[Michael Wild]

Hi all

I opened http://cmake.org/Bug/view.php?id=10747 with a pull-request to improve 
the documentation of the mentioned modules.

Cheers

Michael
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] git help and bug fixes

[Michael Wild]

On 2. Jun, 2010, at 6:47 , James Bigler wrote:

> I have a change I made to master that I didn't push before we changed to the
> New World Order:
> 
> $ git branch
> * master
> $ git log origin/master..master
> commit fcd7a1edcb414a6050dbbcefc0f786143b7fba8a
> Merge: 0d30e3f 7f61960
> Author: James Bigler 
> Date:   Tue Jun 1 21:27:19 2010 -0600
> 
>Merge branch 'master' of git://cmake.org/cmake
> 
> commit 0d30e3fe91717f519722a71470a5180c13818a2a
> Author: James Bigler 
> Date:   Wed May 12 16:38:51 2010 -0600
> 
>Fixed: CUDA_VERSION_MAJOR/MINOR now computed after first run.
> 
>CUDA_VERSION_MAJOR and CUDA_VERSION_MINOR were only computed when
> CUDA_VERSION was first
>computed.  Subsequent runs of FindCUDA would not have
> CUDA_VERSION_MAJOR/MINOR set.  We
>now extract the major and minor versions from the CUDA_VERSION cache
> variable every run.
> 
> ===
> Question: How do I make a topic branch out of this change?
> 

# Option 1:
#
# Create a new topic branch whose HEAD is the commit you want
git branch topics/FixCudaVersion 0d30e3fe91717f519722a71470a5180c13818a2a


# Option 2:
#
# If your master branch has other local commits which you don't want
# to be present in your topic branch, you can either do this:
git branch topics/FixCudaVersion origin/master
git checkout topics/FixCudaVersion
git cherry-pick 0d30e3fe91717f519722a71470a5180c13818a2a

# Option 3:
#
# Or you could do an interactive rebase onto origin/master
git branch topics/FixCudaVersion 0d30e3fe91717f519722a71470a5180c13818a2a
git checkout topics/FixCudaVersion
git rebase -i origin/master
# follow the instructions in the file that should pop up in your favorite 
editor...

# You then can reset your master if you like to
# BEWARE, THIS MIGHT DESTROY INFORMATION!
git checkout master
git reset --hard origin/master
# the HEAD of master is now at the same commit as origin/master is.

> Question: Do I need to push this change to "next"?
> 
> Question: If this is a bug fix, will the release manager push it into 2.8.2
> at some point?


I'll leave the rest of the question for someone from Kitware to answer since I 
have no idea (e.g. do you have commit-rights?).

HTH

Michael

___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Topic-based Git workflow for CMake

[Michael Wild]

On 5. Jun, 2010, at 17:46 , Miguel A. Figueroa-Villanueva wrote:

> On Thu, May 13, 2010 at 11:47 AM, Brad King wrote:
>> Hi Folks,
>> 
>> We are about to switch to a branchy, topic-based workflow for CMake
>> development with Git.  The approach is based on a workflow documented
>> in "git help workflows".  We've written a Wiki page to document it:
>> 
>>  http://public.kitware.com/Wiki/Git/Workflow/Topic
>> 
>> along with step-by-step development instructions.  Please read this
>> carefully before doing any development after the transition to the
>> new workflow.
> 
> Hello Everyone,
> 
> I was reading along the wiki page on the new workflow and in an effort
> to understand things better I would like to have someone clarify
> something about the "avoid the urge to merge" statement. That is, I
> understand the concept and why it is necessary to keep the history
> shape cleaner.
> 
> However, one could have a balance that satisfies both the "urge to
> merge" and the clean history by rebasing the topic branch to the
> current master, right?
> 
> That would change the sequence of commands to something like this
> (bear in mind that I'm not familiar with git, but it should be close):
> 
> # create your topic branch
> git checkout master
> git checkout -b topic
> 
> # do work
> git commit
> git commit
> 
> # rebase to make merging to next easier
> git pull
> git rebase master
> 
> # continue work
> git commit
> git commit
> 
> # finally publish your topic branch
> git checkout next
> git merge topic
> git push
> 
> Of course, this is assuming that the topics (next branch) are merged
> into master frequently. Also, it is only worth it if you are working
> on a feature that takes a long time to develop (otherwise the merge
> will be simple enough without rebasing). Does this make sense or am I
> missing something about how git or the new workflow works?
> 
> Thanks,
> --Miguel

IMHO rebasing is great to keep things up to date when developing a topic. But 
make sure to _NEVER_ rebase a commit you published before. That's going to 
create a lot of trouble. If you read "man gitworkflows" you will see that this 
is not a hard rule, e.g. the git developers themselves use a "throw-away" 
integration branch they call "pu" (proposed updates). At well defined points in 
the development cycle they clean up its history by rebasing/squashing/splitting 
and then merge it into "next". After that a new "pu" branch is created.


HTH

Michael
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] zsh user out there ?

[Michael Wild]

On 22. Jun, 2010, at 17:35 , Brad King wrote:

> Mathieu Malaterre wrote:
>> Hi there,
>> 
>>  Is anyone using fancy zsh script to show git branch directly on the
>> shell ? If so what do you recommend ?
> 
> Look at the __git_ps1 function in git-completion.bash that comes
> with Git:
> 
> http://git.kernel.org/?p=git/git.git;a=blob;f=contrib/completion/git-completion.bash;h=545bd4b38368e3c2a3958133bbeef6a19e831fff;hb=d599e0484f8ebac8cc50e9557a4c3d246826843d
> 
> It sets up the prompt for bash.  It can probably be adapted for zsh.
> 
> That said, there may be support in zsh proper already, but I'm not
> familiar with it.
> 
> -Brad

Indeed, I use the vcs_info module that is included in stock-zsh. Here my setup:

# set up prompt (with VCS info)
autoload -Uz vcs_info
setopt prompt_subst
zstyle ':vcs_info:*' enable git 
zstyle ':vcs_info:*' actionformats 
'%F{magenta}[%s:%F{yellow}%b%f|%F{red}%a%F{magenta}]%f '
zstyle ':vcs_info:*' formats   '%F{magenta}[%s:%F{yellow}%b%F{magenta}]%f '
precmd () {
  vcs_info
  if [ "${vcs_info_msg_0_}" = "" ]; then
dir_status="%f%#"
  elif [[ $(git diff --cached --name-status 2>/dev/null ) != "" ]]; then
dir_status="%F{red}▶%f"
  elif [[ $(git diff --name-status 2>/dev/null ) != "" ]]; then
dir_status="%F{yellow}▶%f"
  else
dir_status="%F{green}▶%f"
  fi  
}
PS1='%f{red}%...@%f{blue}%m %3~ ${vcs_info_msg_0_}${dir_status} '


There's also support for svn, svk, bzr and hg (and possibly others). Refer to 
zshcontrib(1) for more information.

HTH

Michael
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] the first line must not be more than 78 characters

[Michael Wild]

On 30. Jul, 2010, at 10:03 , Mathieu Malaterre wrote:

> Hi there,
> 
>  I tried to push a bug fix to next, but I did get an error back:
> 
> Counting objects: 15, done.
> Delta compression using up to 16 threads.
> Compressing objects: 100% (8/8), done.
> Writing objects: 100% (8/8), 1.58 KiB, done.
> Total 8 (delta 6), reused 0 (delta 0)
> --
> commit 6a3d7d46 has an invalid message:
>  the first line must not be more than 78 characters
> commit message is:
> BUG: 0009611 Fix Arch independent FindJNI.cmake on Linux to support
> Sun Java, OpenJDK, Kaffe and GCJ paths. Based on patch from debian
> --
> error: hook declined to update refs/heads/next
> To g...@cmake.org:cmake.git
> ! [remote rejected] next -> next (hook declined)
> error: failed to push some refs to 'g...@cmake.org:cmake.git'
> 
> 
>  Is there an easy way to change the commit line ?
> 
> Thanks
> -- 
> Mathieu

If the patch in question is HEAD, then just to a "git commit --amend" and edit 
the message. Otherwise, do a "git rebase --interactive commit^" where commit is 
the (partial) hash of the commit in question and in the editor that pops up, 
mark the line with the commit in question with an "e", save and quite and then 
do a "git commit --amend" followed by "git rebase --continue".

There are other, more low-level ways of doing this, but these are pretty 
universal and can also be used for many other purposes.

HTH

Michael

___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Good way to track whether a branch has been merged into master ?

[Michael Wild]

On 19. Sep, 2010, at 11:03 , Alexander Neundorf wrote:

> Hi,
> 
> I'm currently cleaning up my local CMake branches.
> What is a good way to find out whether some branch has been merged into 
> master ? Right now I was looking through "git log" to see whether the commits 
> are in master.
> 
> Alex

Many options come to mind:

1. just try to delete the branch with 'git branch -d '. Git will refuse 
to delete it if the branch hasn't been merged.
2. 'git merge-base  ' shows the last merge point, or if that 
doesn't exist the branching point.
3. 'git show-branch  ' shows the history of both branches 
since the last merge (that's the default, you can show more if you want).
4. 'git log ..' shows all commits in  that are not 
in .

HTH

Michael

--
There is always a well-known solution to every human problem -- neat, 
plausible, and wrong.
H. L. Mencken



PGP.sig
Description: This is a digitally signed message part
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Good way to track whether a branch has been merged into master ?

[Michael Wild]

On 19. Sep, 2010, at 18:52 , David Cole wrote:

> On Sun, Sep 19, 2010 at 5:15 AM, Michael Wild  wrote:
> 
>> 
>> On 19. Sep, 2010, at 11:03 , Alexander Neundorf wrote:
>> 
>>> Hi,
>>> 
>>> I'm currently cleaning up my local CMake branches.
>>> What is a good way to find out whether some branch has been merged into
>>> master ? Right now I was looking through "git log" to see whether the
>> commits
>>> are in master.
>>> 
>>> Alex
>> 
>> Many options come to mind:
>> 
>> 1. just try to delete the branch with 'git branch -d '. Git will
>> refuse to delete it if the branch hasn't been merged.
>> 2. 'git merge-base  ' shows the last merge point, or if
>> that doesn't exist the branching point.
>> 3. 'git show-branch  ' shows the history of both branches
>> since the last merge (that's the default, you can show more if you want).
>> 4. 'git log ..' shows all commits in  that are
>> not in .
>> 
>> HTH
>> 
>> Michael
>> 
>> --
>> There is always a well-known solution to every human problem -- neat,
>> plausible, and wrong.
>> H. L. Mencken
>> 
>> 
>> ___
>> cmake-developers mailing list
>> cmake-developers@cmake.org
>> http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
>> 
>> 
> I would use:
> git branch --contains 
> 
> to find out if a given commit is reachable from a given branch.


Ahh, very useful. There's always something new to discover with git. Sometimes 
I think that git really has an issue with the enormous size of it's UI ;-)

--
There is always a well-known solution to every human problem -- neat, 
plausible, and wrong.
H. L. Mencken



PGP.sig
Description: This is a digitally signed message part
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake code style

[Michael Wild]

On 21. Sep, 2010, at 18:13 , Alexander Neundorf wrote:

> On Tuesday 21 September 2010, Alan W. Irwin wrote:
>> On 2010-09-20 16:20-0400 Bill Hoffman wrote:
>>> BTW, this type of code is not allowed in CMake:
>>> 
>>>  if (fi!=files.begin()) os << ";";
>>> 
>>> Needs to be:
>>> 
>>> if((fi!=files.begin())
>>> {
>>> os << ";";
>>> }
>> 
>> If you want a consistent coding style in CMake, I suggest you give
>> uncrustify a look.  It is extremely powerful and configurable, and we
>> are quite pleased with the results it gives in the PLplot case.
>> 
>> Let's face it, with a variety of humans involved with a code base some
>> inconsistent coding style is constantly creeping in.  To stop that you
>> need (1) some sort of style czar or (2) some semi-automatic script
>> that does the job which one core developer runs by hand aperiodically
>> to bring all code into conformance with a uniform style.  I feel that
>> (2) is the better choice since it gives consistent results and better
>> feelings amongst developers since it is easier to come to consensus on
>> uncrustify options you are going to use then argue over styling of
>> individual files.
> 
> I guess Kitware would favour kwstyle for that job ?
> Last time I checked a few years ago it still had to mature a bit, don't know 
> how it looks today.
> 
> Alex

IMHO the style should be checked using a commit-hook, and if it doesn't match, 
the commit should be refused. The reason why I prefer this over periodically 
run cleanup-scripts is that these scripts make the "blame" operation nearly 
useless. Similarly, I loath "whitespace errors" (inconsistent indentation, 
mixing of tabs/spaces for indents, tabs for alignment, trailing whitespace), 
but I'm also against fixing them for their own sake. I rather keep them until 
that particular line/block needs to be changed otherwise.

Michael

--
There is always a well-known solution to every human problem -- neat, 
plausible, and wrong.
H. L. Mencken



PGP.sig
Description: This is a digitally signed message part
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Instructions for regenerating CMake flex files?

[Michael Wild]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/01/2010 04:07 PM, Hickel, Kelly wrote:
> Hi,
>   I'm looking at porting CMake to z/OS and it seems as though I have a need 
> to regenerate all flex/yacc/bison generated files because the system's 
> character set is EBCDIC.  I've been googling a lot and haven't been able to 
> find any information on how to do this, the bootstrap command doesn't do it 
> and I haven't found anything in any of the files in the 2.8.2 source tarball 
> that really give me any hints, except lines like this in the generated files:
>   Run flex like this:
> flex --prefix=cmListFileLexer_yy -ocmListFileLexer.c 
> cmListFileLexer.in.l
> 
> But, I haven't found any files matching *yy* in the source tarball, or in a 
> cloned copy of the git archive.
> 
> Any tips?
> 
> Thanks,
> 
> 
> Kelly Hickel
> Product Development Architect
> BMC Software

That's because flex files have a .l suffix (in your example it would be
cmListFileLexer.in.l). So, go ahead and run the command as the comment
says (and post-process the output manually, as is also stated in the
comments).

HTH

Michael


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkzO2x0ACgkQyAe0BK8NufPHSACbBd5RsKf1UdWFVGNMGBpH53n4
IccAn1ddqf8ka1f4TVzWjZbPWdFxhTKf
=8Alu
-END PGP SIGNATURE-
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Instructions for regenerating CMake flex files?

[Michael Wild]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/01/2010 05:08 PM, Hickel, Kelly wrote:
> 
> 
>> -Original Message-
>> From: cmake-developers-boun...@cmake.org [mailto:cmake-developers-
>> boun...@cmake.org] On Behalf Of Michael Wild
>> Sent: Monday, November 01, 2010 10:22 AM
>> To: cmake-developers@cmake.org
>> Subject: Re: [cmake-developers] Instructions for regenerating CMake
>> flex files?
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 11/01/2010 04:07 PM, Hickel, Kelly wrote:
>>> Hi,
>>>   I'm looking at porting CMake to z/OS and it seems as though I have
>> a need to regenerate all flex/yacc/bison generated files because the
>> system's character set is EBCDIC.  I've been googling a lot and haven't
>> been able to find any information on how to do this, the bootstrap
>> command doesn't do it and I haven't found anything in any of the files
>> in the 2.8.2 source tarball that really give me any hints, except lines
>> like this in the generated files:
>>> Run flex like this:
>>>   flex --prefix=cmListFileLexer_yy -ocmListFileLexer.c
>> cmListFileLexer.in.l
>>>
>>> But, I haven't found any files matching *yy* in the source tarball,
>> or in a cloned copy of the git archive.
>>>
>>> Any tips?
>>>
>>> Thanks,
>>>
>>>
>>> Kelly Hickel
>>> Product Development Architect
>>> BMC Software
>>
>> That's because flex files have a .l suffix (in your example it would be
>> cmListFileLexer.in.l). So, go ahead and run the command as the comment
>> says (and post-process the output manually, as is also stated in the
>> comments).
>>
>> HTH
>>
>> Michael
>>
> 
> Ahh, the power that Monday doth posses to make one feel an idiot.
> 
> You mean I actually have to READ what's in the file?   AND follow directions?
> 
> Yikes!   ;-}
> 
> Thanks Michael,
> Kelly
> 

It does help occasionally, no matter how contrary to intuition it might
be ;-)

Michael
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkzO5+cACgkQyAe0BK8NufN+OACghqjYjKUXQjRt/IXi2ZDW/yXQ
xj0An2pzMVcvKWsMO4H1noP3wn0gU03u
=87cj
-END PGP SIGNATURE-
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Failing HTML (xmllint) test in the CMake dashboard results...

[Michael Wild]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/01/2010 11:38 PM, David Cole wrote:
> Starting last Friday, apparently unrelated to any CMake source code
> changes, the CMake.HTML test started failing on several platforms:
> 
> http://www.cdash.org/CDash/queryTests.php?project=CMake&date=2010-11-01&filtercount=1&showfilters=1&field1=testname/string&compare1=63&value1=HTML
> 
> It appears to be a "403/forbidden" error from the xmllint output.
> 
> It seems that all of the failing platforms have older xmllint
> installs, and do not support the "--nonet" command line arg.
> 
> Does anybody know what might have changed to cause this? (Some setting
> on the w3.org web server?)
> 
> You can see the CMakeLists code that adds the test at
> CMake/Utilities/CMakeLists.txt, starting around line 140.
> 
> I am at a loss and I'm not sure what we should do about it. It is nice
> to think that the HTML documentation that we generate is checked and
> validated against the schemas available from w3.org... But to be
> really useful, we need the test to be reliable. As it stands, I'm
> leaning towards disabling the test on xmllint installs that do not
> support "--nonet".
> 
> Any HTML / xmllint experts out there that can chime in and point out
> what's wrong so we can get it fixed?
> 
> 
> Thanks,
> David Cole

Looks like w3c has had enough of the excessive traffic (although the
post is back from 2008):

http://www.w3.org/blog/systeam/2008/02/08/w3c_s_excessive_dtd_traffic

A solution might be to ship your own copy of the DTD and the entity
files (xhtml1-strict.dtd, xhtml-lat1.ent, xhtml-special.ent and
xhtml-symbol.ent), just for the purpose of testing. You could then set
XML_CATALOG_FILES to some xml-catalog containing something like this:


http://globaltranscorp.org/oasis/catalog/xml/tr9401.dtd";>







I just tried it and it seems to work on my machine.

Michael
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkzPyPYACgkQyAe0BK8NufPCmQCfT3vESnKz7hmLbAnUVSckHSdT
3GgAnjfdVFrvOVtrlDpYXRxJ3XYL0/RC
=Mhqg
-END PGP SIGNATURE-
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Failing HTML (xmllint) test in the CMake dashboard results...

[Michael Wild]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/02/2010 01:25 PM, Bill Hoffman wrote:
> On 11/2/2010 4:16 AM, Michael Wild wrote:
> 
>>> David Cole
>>
>> Looks like w3c has had enough of the excessive traffic (although the
>> post is back from 2008):
>>
>> http://www.w3.org/blog/systeam/2008/02/08/w3c_s_excessive_dtd_traffic
>>
> 
> Odd thing is, it fails all the time.  If you run xmllint from the
> command line, it always fails now.  It is very consistent.  It does not
> act like an overloaded server.
> 
>> A solution might be to ship your own copy of the DTD and the entity
>> files (xhtml1-strict.dtd, xhtml-lat1.ent, xhtml-special.ent and
>> xhtml-symbol.ent), just for the purpose of testing. You could then set
>> XML_CATALOG_FILES to some xml-catalog containing something like this:
>>
>> 
>> > V1.0-Based Extension V1.0//EN"
>>  "http://globaltranscorp.org/oasis/catalog/xml/tr9401.dtd";>
>>
>> >   xmlns:soc="urn:oasis:names:tc:entity:xmlns:tr9401:catalog"
>>   xmlns:unk="urn:oasis:names:tc:entity:xmlns:unknown"
>>   >
>> 
>> >uri="xhtml1-strict.dtd"/>
>> 
>> 
>>
>> I just tried it and it seems to work on my machine.
>>
> Sure, I suppose we could do that. Would be interesting to figure out
> what happened...
> 
> -Bill

Seems like W3C is now requiring the User-Agent header, otherwise you get
a 403 response. Using wireshark I found that xmllint doesn't send a
User-Agent identification, and gets rejected. If I use wget and tell it
to suppress the User-Agent header I also get the same result:

$ wget --user-agent="" http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd
- --2010-11-02 15:06:52--  http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd
Resolving www.w3.org... 128.30.52.37
Connecting to www.w3.org|128.30.52.37|:80... connected.
HTTP request sent, awaiting response... 403 Forbidden
2010-11-02 15:06:53 ERROR 403: Forbidden.

The same works fine when using the default options.

Michael
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkzQHAgACgkQyAe0BK8NufM+QQCffpHrEywu/KDA5ktxfViAFUrm
4ZIAnR078I5sZjjdD9Q60YjMIKES3bOF
=CEw3
-END PGP SIGNATURE-
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Failing HTML (xmllint) test in the CMake dashboard results...

[Michael Wild]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/02/2010 04:05 PM, Bill Hoffman wrote:
> On 11/2/2010 10:11 AM, Michael Wild wrote:
> 
>> Seems like W3C is now requiring the User-Agent header, otherwise you get
>> a 403 response. Using wireshark I found that xmllint doesn't send a
>> User-Agent identification, and gets rejected. If I use wget and tell it
>> to suppress the User-Agent header I also get the same result:
>>
>> $ wget --user-agent="" http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd
>> - --2010-11-02 15:06:52-- 
>> http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd
>> Resolving www.w3.org... 128.30.52.37
>> Connecting to www.w3.org|128.30.52.37|:80... connected.
>> HTTP request sent, awaiting response... 403 Forbidden
>> 2010-11-02 15:06:53 ERROR 403: Forbidden.
>>
>> The same works fine when using the default options.
>>
> 
> That explains it!
> 
> Thanks.
> 
> Looks like we should disable xmllint for older versions of xmllint.
> 
> 
> -Bill

But then, if you use --nonet, you require that the machine has the DTD
installed locally and that it can be resolved by the default catalog,
otherwise the validation will fail too. But this is probably just
something the person setting up the dashboard has to remember...

Michael

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkzQNhkACgkQyAe0BK8NufNyrQCfW7gt33j/u9yXuhPFXOuHxPlG
YOsAnjNRFwo2OXsgCkwW+pFbqW6o2wqg
=CRSH
-END PGP SIGNATURE-
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Failing HTML (xmllint) test in the CMake dashboard results...

[Michael Wild]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

- From my experiments, --dtdvalid is not enough. No matter what I try,
xmllint still wants to resolve
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd. The only way that
worked for me was a catalog file. So, I suggest you add a minimal
catalog file like I proposed to the CMake/utilties/xml directory and use
the ENVIRONMENT test property to set
XML_CATALOG_FILES=${CMAKE_SOURCE_DIR}/utilities/xml/catalog.xml.

HTH

Michael


On 11/02/2010 05:19 PM, David Cole wrote:
> I just merged this commit into 'next' :
> http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bb1df1ec8ea880c9859845b85828b8b724abb1ba
> 
> It will definitively highlight for us all the submitting dashboard
> machines that are *not* using the "--nonet" argument to xmllint.
> 
> Then, after tomorrow's run, we can decide what we want to do about it.
> Either replace it with a test that does the equivalent, but without
> network access, or eliminate those machines (leave the test empty in
> the "else()" block) and just be happy with the test running on the
> machines that do have "--nonet" access.
> 
> Michael, we do have a local copy of the dtd anyhow in
> CMake/Utilities/xml -- but I'm not convinced we're calling xmllint
> correctly even in the --nonet case, as I still see "failed network
> I/O" types of error messages from xmllint when I run it by hand.
> 
> I think we may either need a catalog as you suggest, or at least a
> "--dtdvalid" arg to xmllint in addition to what we're doing now.
> 
> Do you have a suggestion one way or the other about the optimal resolution 
> here?
> 
> Thanks for your help with this,
> David
> 
> 
> On Tue, Nov 2, 2010 at 12:02 PM, Michael Wild  wrote:
> On 11/02/2010 04:05 PM, Bill Hoffman wrote:
>>>> On 11/2/2010 10:11 AM, Michael Wild wrote:
>>>>
>>>>> Seems like W3C is now requiring the User-Agent header, otherwise you get
>>>>> a 403 response. Using wireshark I found that xmllint doesn't send a
>>>>> User-Agent identification, and gets rejected. If I use wget and tell it
>>>>> to suppress the User-Agent header I also get the same result:
>>>>>
>>>>> $ wget --user-agent="" http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd
>>>>> - --2010-11-02 15:06:52--
>>>>> http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd
>>>>> Resolving www.w3.org... 128.30.52.37
>>>>> Connecting to www.w3.org|128.30.52.37|:80... connected.
>>>>> HTTP request sent, awaiting response... 403 Forbidden
>>>>> 2010-11-02 15:06:53 ERROR 403: Forbidden.
>>>>>
>>>>> The same works fine when using the default options.
>>>>>
>>>>
>>>> That explains it!
>>>>
>>>> Thanks.
>>>>
>>>> Looks like we should disable xmllint for older versions of xmllint.
>>>>
>>>>
>>>> -Bill
> 
> But then, if you use --nonet, you require that the machine has the DTD
> installed locally and that it can be resolved by the default catalog,
> otherwise the validation will fail too. But this is probably just
> something the person setting up the dashboard has to remember...
> 
> Michael
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkzQRU4ACgkQyAe0BK8NufO4XwCggscDNEcnmaXSg9hbT4S+yIEQ
vb4AnA3xs/61hl+QSVBW9LMPiniLeRDF
=5JD4
-END PGP SIGNATURE-
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] [CMake 0011209]: Support generator expression everywhere they make sense

[Michael Wild]

Thanks Brad, that's fantastic! Kind of a premature Christmas gift ;-)

Michael

On 12/15/2010 09:43 PM, Mantis Bug Tracker wrote:
> 
> The following issue has been RESOLVED. 
> == 
> http://public.kitware.com/Bug/view.php?id=11209 
> == 
> Reported By:    Michael Wild
> Assigned To:Brad King
> == 
> Project:CMake
> Issue ID:   11209
> Category:   CMake
> Reproducibility:N/A
> Severity:   feature
> Priority:   normal
> Status: resolved
> Resolution: fixed
> Fixed in Version:   
> == 
> Date Submitted: 2010-09-07 02:10 EDT
> Last Modified:  2010-12-15 15:43 EST
> == 
> Summary:Support generator expression everywhere they make
> sense
> Description: 
> It would be very convenient if CMake supported the generator expressions
> available in the ADD_TEST command in all user-definable commands that run at
> build time. ADD_CUSTOM_COMMAND and ADD_CUSTOM_TARGET spring to mind.
> ==
> Relationships   ID  Summary
> --
> related to  0009974 CMake should support custom commands th...
> == 
> 
> -- 
>  (0024189) Brad King (developer) - 2010-12-15 15:36
>  http://public.kitware.com/Bug/view.php?id=11209#c24189 
> -- 
> I've wanted to do this feature for a long time.  I finally got my chance this
> month and have been working on it for a couple weeks.
> 
> The main commit is
> 
>   http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f0cdb600
> 
> but a lot of refactoring and cleanup was needed to get to that point.  The 
> full
> commit range produced by this effort was
> 
>   git log --graph afc89064..f0cdb600 
> 
> -- 
>  (0024190) Brad King (developer) - 2010-12-15 15:42
>  http://public.kitware.com/Bug/view.php?id=11209#c24190 
> -- 
> Commit f0cdb600 adds support for generator expressions in add_custom_command 
> and
> add_custom target.  They already work in add_test.
> 
> The only other place I can think that non-C++ (pure CMake) code can define
> commands is the Makefile generator rule variables like
> CMAKE__COMPILE_OBJECT.  These are very specific to one generator 
> though. 
> Actually the placeholder syntax they use, such as "", was one of the
> reasons we chose $<> syntax for generator expressions in the first place.  We
> anticipated adding them elsewhere beyond add_test.  However, since rule
> variables are already expanded with per-configuration substitution I don't
> currently see a use case for generator expressions there.  Although it may 
> help
> cleanup our builtin rule variables we would always have to support the 
> old-style
> placeholders so I don't want to add extra code until we have a good reason. 
> 
> Issue History 
> Date ModifiedUsername   FieldChange   
> == 
> 2010-09-07 02:10 Michael Wild   New Issue
> 2010-12-15 12:02 David Cole Assigned To   => Brad King   
> 2010-12-15 12:02 David Cole Status   new => assigned 
> 2010-12-15 14:28 Brad King  Relationship added   related to 0009974  
> 2010-12-15 15:36 Brad King  Note Added: 0024189  
> 2010-12-15 15:42 Brad King  Note Added: 0024190  
> 2010-12-15 15:43 Brad King  Status   assigned => resolved
> 2010-12-15 15:43 Brad King  Resolution   open => fixed   
> ==
> 

___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Generating information for C++ tools in cmake (patch)

[Michael Wild]

On 01/13/2011 09:38 PM, Manuel Klimek wrote:
> On Thu, Jan 13, 2011 at 11:43 AM, Alexander Neundorf  wrote:
>> On Wednesday 12 January 2011, Manuel Klimek wrote:
>> ...
>>> Yes, I agree that it is very conceivable that we'll want that in the
>>> future - one reason I propose a JSON format is that it is both easy to
>>> parse and easy to extend.
>>
>> Any special reason why you choose json and not xml ?
>> xml is still a bit more widespread.
> 
> Yes. Parsing speed matters. Tools that run will need to parse a
> potentially pretty big file. I don't have any numbers, so it's all
> based on experience I have from 5 years ago where parsing XML was
> painfully slow. If somebody has numbers, I'm happy to reconsider the
> format ...
> 
>> I have two things in mind (not short term, but mid or long term):
>>
>> * have cmake write some project or buildfile which can be used as a 
>> build-tool
>> independent buildfile ... well, i.e. it should contain all information to
>> build the project (as makefiles do), be easily parseble (e.g. xml or json...)
>> and provide enough information for IDEs, so that e.g. QtCreator could use
>> this as primary project file. It should be possible that it includes not only
>> the commands to compile the files, but also to link, to install, to
>> preprocess only, etc. This would probably be the file you are writing now,
>> but heavily extended later on.
> 
> While I see how this might be useful, it is orthogonal to the matter
> I'm trying to solve, and I would vote for putting it into 2 different
> files (again because I want the parsing to be fast).
> The problem I'm currently solving is "how to understand the C/C++ code
> in the project". What you propose would include all the dependencies,
> which are a pretty huge extra chunk of information.
> 
>> * have cmake install some FooConfig.xml or FooConfig.json file (instead or
>> additionally to FooConfig.cmake), which contains information about an
>> installed package (like pkg-config), and which can be easily parsed by other
>> tools (e.g. xml or json). This is only related to what you are doing now in
>> that I think it should use the same markup language as that will use one day.
> 
> Agreed.
> 
>> I would have opted for xml, but simply because I consider it the default
>> choice. I don't have a real opinion on json.
> 
> As I said, if you can make a good case for parsing XML files at the
> same speed we can parse JSON, I'm happy to reconsider.
> One thing we could probably do is define a subset of XML for this file
> and use that, which would bring parsing speed up to par, but of course
> would get rid of many of the reasons you would want XML in the first
> place.
> 
> Cheers,
> /Manuel

Just to throw in another alternative: YAML is a superset of JSON with
added benefits, such as:

- Extensible data types.

- Relational data (i.e. you don't have to repeat identical data, just
refer to it via a an anchor). This is possibly the biggest advantage.

- Allows for block-indentation (similar to Python) without requiring
delimiters (braces, brackets, quotes).


Michael
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Generating information for C++ tools in cmake (patch)

[Michael Wild]

On 01/14/2011 02:25 PM, Brad King wrote:
> On 01/13/2011 06:05 PM, Manuel Klimek wrote:
>> I think that finding this file in the same spot relative to the base
>> build directory independently of the build system used will make it a
>> lot easier for tool-smiths / users to actually make use of it. If you
>> want to hide it away, I'd vote for a more build system independent
>> name than CMakeFiles.
> 
> CMake used to write lots of files to the top of the build tree but many
> people complained about the verbosity, especially for in-source builds.
> Now we hide as many files as possible under CMakeFiles/ subdirectories.
> If the file must go in the top level then I'd prefer to enable it only
> optionally as discussed previously.
> 
>>> About the content of the json file: I suggest that each command also
>>> include a "language" field indicating "C", "C++", or "Fortran".
>>
>> I'd rather keep it focused for now, and add additional things later if
>> you're ok with that.
> 
> Okay.  Does JSON support any kind of schema?
> 
> -Brad


There are a number of schema implementations/attempts, e.g.:

http://json-schema.org/

http://www.kuwata-lab.com/kwalify

Michael
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake to GMake issues

[Michael Wild]

On 01/24/2011 06:02 PM, Chris Lawrence wrote:
> Hi,
> 
> I've recently been looking into using CMake with one of my projects at
> work. I've recently run into a problem where the Makefile, CMake
> generates will not run on my build system unless I install the cmake
> libraries.
> 
> Just to clarify, my development machine (where CMake is installed) and
> my build machine are separate. My project requires the use of the
> generated makefile, without the dependence of having cmake installed on
> that machine.
> 
> Is there any flags available for CMake, to generate a gmake file that
> can be run independently from the cmake libraries?
> 
> Kind regards,
> 
> Chris

No.

CMake is used for generating the progress output, dependency scanning
and probably quite a few more things. The generated build systems are
never "standalone".

HTH

Michael
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] [CMake] namespace support

[Michael Wild]

On 02/03/2011 08:04 PM, Bill Hoffman wrote:
> On 2/3/2011 12:20 PM, Peter Kümmel wrote:
>> On 03.02.2011 17:20, Peter Kümmel wrote:
>>> Because good solution is not available
>>> I've added the mentioned namespace support
>>> to CMake:
>>>
>>> namespace()
>>> endnamespace()
>>>
>>> With attached patch it is possible to write
>>> code like this (imagine antiX.cpp does not
>>> compile when the macro X is set):
>>>
>>> namespace(x)
>>> add_definitions(-DX)
>>> add_library(X x.cpp)
>>> endnamespace()
>>> add_library(antiX antiX.cpp)
>>>
>>>
>>> The ticket is here
>>> http://www.cmake.org/Bug/view.php?id=11793
>>>
>>>
>>> I hope it could be added in this or an
>>> similar form to CMake.
>>>
>>
>> For simpler testing I've uploaded
>> Windows and Linux binaries here:
>>
>> https://sourceforge.net/projects/cmakescript/files/CMake%20namespace/
>>
> 
> This would be better discussed on the cmake-developers mailing list.
> 
> -Bill

Although I consider the functionality this patch adds to be useful and
desirable, I would prefer to have INCLUDE_DIRECTORIES target and
source-file properties.

My 2c...

Michael

___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] The CMake bug tracker and "the backlog" of unresolved issues

[Michael Wild]

On 02/03/2011 11:34 PM, David Cole wrote:
> Hello CMakers,
> 
> The CMake issue tracker is located at:
> http://public.kitware.com/Bug
> 
> All of the issues except for the most recent 15 or so have been assigned and
> looked at by at least one CMake developer at one point in each issue's
> history. However, not all issues that are assigned to developers are being
> actively worked on. Personally, I have just over 100 issues assigned to me,
> and I know it would take me on the order of months to work through all of
> them, even if I were able to work on them full time.
> 
> I would like very much for us to introduce the notion of a "backlog" in the
> CMake bug tracker, where we can send bugs that are not being actively worked
> on, and we can review the backlog periodically for issues that should be
> brought forward into active development again.
> 
> Since we do not have a status of "backlog" -- but we don't really use the
> status values of "acknowledged" or "confirmed" very much, I am thinking we
> could define "backlog" as:
>  status=acknowledged
>AND
>  assigned to="" (empty string, none)
> 
> As an exemplar, I just sent this one to the backlog by  setting its status
> and de-assigning it:
>  http://public.kitware.com/Bug/view.php?id=7867
> 
> Does this seem like a reasonable technique? Any comments or questions before
> we start sending more things to the backlog?
> 
> When we send around the request (coming up soon, after the final 2.8.4
> release is ready) to vote for your favorite issues... you'd still be able to
> vote for things in the backlog. And if we can find somebody willing to do
> the work, we'll assign it to them and set status=assigned again...
> 
> 
> Let me know what you think -- thanks for reading,
> David

You could actually add a "backlog" status by customising the configuration:

http://manual.mantisbt.org/manual.customizing.mantis.customizing.status.values.php

This would be IMHO much less confusing and also much easier to use when
searching/filtering.

Michael
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Ability to iterate over all targets?

[Michael Wild]

On 02/09/2011 04:24 PM, Johan Björk wrote:
> Hi everyone,
> 
> There seems to be quite a few requests to be able to iterate over all the
> targets
> http://www.cmake.org/pipermail/cmake/2010-September/039379.html
> http://www.mail-archive.com/cmake@cmake.org/msg09544.html
> http://www.mail-archive.com/cmake@cmake.org/msg33947.html
> 
> I haven't seen any changes or bug reports allowing this.. has anyone
> considered adding it?
> 
> My usecase is a bit different then the others. I have a common 'core'
> library that itself contains a bunch of static libraries. We have several
> targets that utilize this common core, and for our iPhone target, I must set
> a certain XCode attribute for all targets.
> While overriding the add_library() call works, it feels like an ugly hack.
> 
> Thanks
> /Johan

Then don't override it, wrap it in a function instead. This is
semantically clearer (if you give it a good name) and has the advantage
that it's clear what's going on. Iterating over a list of targets to
modify properties in a possibly distant part of the build system isn't
very transparent IMHO.

That's not to say I wouldn't like to have a way of obtaining a list of
targets defined so far...


Michael
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] [PATCH] Also match "error" at start of line as build error, not only "Error"

[Michael Wild]

On 04/14/2011 09:12 AM, Rolf Eike Beer wrote:
> Doesn't make any sense to me not to catch those, too.
> 
> Eike
> 
> 
> 0001-make-some-Error-match-strings-also-match-error.patch
> 
> 
> From 4e6296a227b939e343949ec1452a59829f0ca6bd Mon Sep 17 00:00:00 2001
> From: Rolf Eike Beer 
> Date: Thu, 14 Apr 2011 09:08:13 +0200
> Subject: [PATCH] make some "Error" match strings also match "error"
> 
> This was not flagged as build error in CDash in one of our builds:
> 
> error: reading config file failed
> ---
>  Source/CTest/cmCTestBuildHandler.cxx |6 +++---
>  1 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/Source/CTest/cmCTestBuildHandler.cxx 
> b/Source/CTest/cmCTestBuildHandler.cxx
> index 86bd85d..87840d8 100644
> --- a/Source/CTest/cmCTestBuildHandler.cxx
> +++ b/Source/CTest/cmCTestBuildHandler.cxx
> @@ -46,10 +46,10 @@ static const char* cmCTestErrorMatches[] = {
>":.*[Pp]ermission [Dd]enied",
>"([^ :]+):([0-9]+): ([^ \\t])",
>"([^:]+): error[ \\t]*[0-9]+[ \\t]*:",
> -  "^Error ([0-9]+):",
> +  "^[Ee]rror ([0-9]+):",
>"^Fatal",
> -  "^Error: ",
> -  "^Error ",
> +  "^[Ee]rror: ",
> +  "^[Ee]rror ",
>"[0-9] ERROR: ",
>"^\"[^\"]+\", line [0-9]+: [^Ww]",
>"^cc[^C]*CC: ERROR File = ([^,]+), Line = ([0-9]+)",

Would make even more sense to use

"^[Ee][Rr][Rr][Oo][Rr]:? "

Michael
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] [PATCH] Also match "error" at start of line as build error, not only "Error"

[Michael Wild]

On 04/14/2011 11:09 AM, Rolf Eike Beer wrote:
>> On 04/14/2011 09:12 AM, Rolf Eike Beer wrote:
>>> Doesn't make any sense to me not to catch those, too.
>>>
>>> Eike
>>>
>>>
>>> 0001-make-some-Error-match-strings-also-match-error.patch
>>>
>>>
>>> From 4e6296a227b939e343949ec1452a59829f0ca6bd Mon Sep 17 00:00:00 2001
>>> From: Rolf Eike Beer 
>>> Date: Thu, 14 Apr 2011 09:08:13 +0200
>>> Subject: [PATCH] make some "Error" match strings also match "error"
>>>
>>> This was not flagged as build error in CDash in one of our builds:
>>>
>>> error: reading config file failed
>>> ---
>>>  Source/CTest/cmCTestBuildHandler.cxx |6 +++---
>>>  1 files changed, 3 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/Source/CTest/cmCTestBuildHandler.cxx
>>> b/Source/CTest/cmCTestBuildHandler.cxx
>>> index 86bd85d..87840d8 100644
>>> --- a/Source/CTest/cmCTestBuildHandler.cxx
>>> +++ b/Source/CTest/cmCTestBuildHandler.cxx
>>> @@ -46,10 +46,10 @@ static const char* cmCTestErrorMatches[] = {
>>>":.*[Pp]ermission [Dd]enied",
>>>"([^ :]+):([0-9]+): ([^ \\t])",
>>>"([^:]+): error[ \\t]*[0-9]+[ \\t]*:",
>>> -  "^Error ([0-9]+):",
>>> +  "^[Ee]rror ([0-9]+):",
>>>"^Fatal",
>>> -  "^Error: ",
>>> -  "^Error ",
>>> +  "^[Ee]rror: ",
>>> +  "^[Ee]rror ",
>>>"[0-9] ERROR: ",
>>>"^\"[^\"]+\", line [0-9]+: [^Ww]",
>>>"^cc[^C]*CC: ERROR File = ([^,]+), Line = ([0-9]+)",
>>
>> Would make even more sense to use
>>
>> "^[Ee][Rr][Rr][Oo][Rr]:? "
> 
> Probably, but I don't know if the regex implementation understands '?'. At
> least it is never used in those expressions.
> 
> Eike

Reading Source/kwsys/RegularExpression.hxx.in it seems so. You could
also split it in two expressions, the important part was that any
capitalization of ERROR would be matched.

Michael
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] PCRE

[Michael Wild]

On 05/15/2011 07:23 PM, Pau Garcia i Quiles wrote:
> Hi,
> 
> Just a quick note to let you Debajyoti Datta will be implementing
> Perl-compatible Regular Expression support in CMake starting next
> Friday.
> 
> I am mentoring him in Season of KDE (kind of Google Summer of Code,
> but for KDE). Some details of what he will be doing here here:
> http://www.elpauer.org/?p=684
> 
> I've just sent him a long e-mail with the technical details and the
> source of my half-baked implementation. If you are interested in those
> details too, just ask me and I'll forward the e-mail.
> 
> We will not be replacing the current regex support in CMake but only
> adding PCRE in addition to the current regex support. Wherever you
> find now regex support, there will be also PCRE support. I have been
> trying to do this for years (!!!) but I never found enough spare time
> to complete it.
> 
> Debajyoti will introduce himself here soon and the technical issues
> will be discussed here, so that other developers can also give him
> some insight.
> 
> 

Wow, that is some great news! I always missed repeat counts and
predefined character classes the most.

Michael
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Making _IMPORT_PREFIX from an installed exports-file available to an including file

[Michael Wild]

On 06/04/2011 10:28 PM, Alexander Neundorf wrote:
> Hi,
> 
> when installing an export-file cmake has the nice feature to calculate the 
> CMAKE_INSTALL_PREFIX from the current location:
> 
> -8<--8<--8<
> # Compute the installation prefix relative to this file.
> GET_FILENAME_COMPONENT(_IMPORT_PREFIX "${CMAKE_CURRENT_LIST_FILE}" PATH)
> GET_FILENAME_COMPONENT(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH)
> GET_FILENAME_COMPONENT(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH)
> GET_FILENAME_COMPONENT(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH)
> GET_FILENAME_COMPONENT(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH)
> 
> # Import target "bar" for configuration ""
> SET_PROPERTY(TARGET bar APPEND PROPERTY IMPORTED_CONFIGURATIONS NOCONFIG)
> ...
> 
> # Cleanup temporary variables.
> SET(_IMPORT_PREFIX)
> -8<--8<--8<
> 
> 
> I can't do this in cmake-script in a FooConfig.cmake file myself, there I 
> simply must assume that if I go four levels up that I have reached my install 
> prefix. This will usually be correct, but it would be nicer if I could reuse 
> this knowledge which cmake generates into the per-configuration files.
> 
> So, I'd like to do from my FooConfig.cmake file something like:
> 
> include(${CMAKE_CURRENT_LIST_DIR}/FooExports.cmake)
> set(FOO_INCLUDE_DIR ${FooExports_IMPORT_PREFIX}/include )
> 
> Related to this, why is this location computed in the configuration-specific 
> file, and not once in the "parent" exports-file, which includes all the 
> export-files for the different configurations ?
> The files which will be included are collected with this call:
> FILE(GLOB CONFIG_FILES "${_DIR}/BarTargets-*.cmake")
> 
> I.e. it is guaranteed that they are all in the same directory as the 
> including 
> file.
> Doesn't that mean that they are also in the same directory relative to their 
> respective install prefix ?
> 
> If so, would it be ok if I move the code for calculating the IMPORT_PREFIX 
> into the "parent" exports file ?
> 
> Or should I add basically the same code in the generated "parent" 
> exports-file 
> ?
> 
> Alex


I usually hard-code the relative path from the FooConfig.cmake file to
the install-prefix and other installation directories using
configure_file(). E.g:

CMakeLists.txt:
8<--
# ...

set(INSTALL_BIN_DIR bin CACHE PATH
  "Installation directory for runtime binaries")
set(INSTALL_LIB_DIR lib CACHE PATH
  "Installation directory for libraries")
set(INSTALL_INCLUDE_DIR include CACHE PATH
  "Installation directory for headers")
if(WIN32 AND NOT CYGWIN)
  set(DEF_INSTALL_CMAKE_DIR CMake)
  set(DEF_INSTALL_DATA_DIR data)
else()
  set(DEF_INSTALL_CMAKE_DIR share/Foo)
  set(DEF_INSTALL_CMAKE_DIR share/Foo/CMake)
endif()
set(INSTALL_DATA_DIR ${DEF_INSTALL_DATA_DIR} CACHE PATH
  "Installation directory for data files")
set(INSTALL_CMAKE_DIR ${DEF_INSTALL_CMAKE_DIR} CACHE PATH
  "Installation directory for CMake files")
file(RELATIVE_PATH CONF_REL_INSTALL_PREFIX "${INSTALL_CMAKE_DIR}"
"${CMAKE_INSTALL_PREFIX}")
foreach(v BIN LIB INCLUDE DATA)
  if(NOT IS_ABSOLUTE "${INSTALL_${v}_DIR}")
set(INSTALL_${v}_DIR "${CMAKE_INSTALL_PREFIX}/${INSTALL_${v}_DIR}")
  endif()
  file(RELATIVE_PATH CONF_REL_${v}_DIR "${INSTALL_CMAKE_DIR}"
  "${INSTALL_${v}_DIR}")
endforeach()

configure_file(FooConfig.cmake.in
"${PROJECT_BINARY_DIR}/CMake/FooConfig.cmake" @ONLY)

set(CMAKE_RUNTIME_OUTPUT_DIRECTORY "${PROJECT_BINARY_DIR}/bin")
set(CMAKE_LIBRARY_OUTPUT_DIRECTORY "${PROJECT_BINARY_DIR}/lib")
set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY "${PROJECT_BINARY_DIR}/lib")

set(FOO_HDRS
  include/foo.h
  include/bar.h
  include/baz.h)
# copy headers into build tree so we don't have to embed the
# PROJECT_SOURCE_DIR variable in the FooConfig.cmake file
foreach(h IN LISTS FOO_HDRS)
  get_filename_component(hh "${h}" NAME)
  configure_file(${h} "${PROJECT_BINARY_DIR}/include/${hh}" COPYONLY)
endforeach()

#...
8<--

FooConfig.cmake.in:
8<--
# ...

get_filename_component(FOO_CMAKE_DIR "${CMAKE_CURRENT_LIST_FILE}" PATH)
if(EXISTS "${_FOO_CMAKE_DIR}/../CMakeCache.txt")
  # in build tree
  get_filename_component(FOO_INSTALL_PREFIX "${FOO_CMAKE_DIR}" PATH)
  set(FOO_BIN_DIR "${_FOO_PREFIX}/bin")
  set(FOO_LIB_DIR "${_FOO_PREFIX}/lib")
  set(FOO_INCLUDE_DIR "${_FOO_PREFIX}/include")
else()
  set(FOO_INSTALL_PREFIX "${FOO_CMAKE_DIR}/@CONF_REL_INSTALL_PREFIX@")
  set(FOO_BIN_DIR "${FOO_CMAKE_DIR}/@CONF_REL_BIN_DIR@")
  set(FOO_LIB_DIR "${FOO_CMAKE_DIR}/@CONF_REL_LIB_DIR@")
  set(FOO_INCLUDE_DIR "${FOO_CMAKE_DIR}/@CONF_REL_INCLUDE_DIR@")
endif()

# ...
8<--

Of course, this is all from memory and only should illustrate the way
that works best for me...

HTH

Michael
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developer

Re: [cmake-developers] Making _IMPORT_PREFIX from an installed exports-file available to an including file

[Michael Wild]

On 06/05/2011 08:50 PM, Alexander Neundorf wrote:
> On Sunday, June 05, 2011 11:50:12 AM Michael Wild wrote:
>> On 06/04/2011 10:28 PM, Alexander Neundorf wrote:
>>> Hi,
>>>
>>> when installing an export-file cmake has the nice feature to calculate
>>> the CMAKE_INSTALL_PREFIX from the current location:
> ...
>>> If so, would it be ok if I move the code for calculating the
>>> IMPORT_PREFIX into the "parent" exports file ?
>>>
>>> Or should I add basically the same code in the generated "parent"
>>> exports-file ?
>>>
>>> Alex
>>
>> I usually hard-code the relative path from the FooConfig.cmake file to
>> the install-prefix and other installation directories using
>> configure_file(). E.g:
> 
> Good idea, thanks :-)
> You just influenced the future of KDE... ;-)
> 
> Alex

Wow, I'm really honored ;-) Enjoy your stay  in Randa and make sure to
visit the Gornergrat for the best view of our alps!

Michael
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Make non-REQUIRED find_package() always disable-able Was: Re: Adding argument "OPTIONAL" to find_package() and add_subdirectory

[Michael Wild]

On 06/07/2011 10:28 AM, Alexander Neundorf wrote:
> Hi,
> 
> I slept over it, I think here's a better idea.
> 
> For every find_package() which is not REQUIRED, some people or packagers may 
> want to explicitely disable each one of them.
> 
> So how about this:
> if there is no REQUIRED keyword in the find_package() call, there is always 
> an 
> option added which can be used to disable this find_package() call.
> These options could be named DISABLE_PACKAGE_.
> 
> This would
> 1) make it possible to disable each of the optional dependencies explicitely
> 2) these options will have the same standard name in all projects
> 3) does not add additional arguments to the find_package() interface
> 
> Options 1) and 2) are things regularly requested from developers used to 
> autotools.
> 
> Alex


I would like to have such a feature. However, there is another use-case
not covered by your proposal which is important for me. In my packages I
include important dependencies and offer the user the choice to either

1. use the system-installed dependency if it is available
2. build the dependency from the code included in the package
3. if it is an optional dependency, don't use it at all

I have some logic which goes along the following lines (for an optional
dependency):

option(DISABLE_PACKAGE_ "Don't use " OFF)
if(NOT DISABLE_PACKAGE_)
  find_package()
  if(_FOUND)
set(_DEFAULT_USE_SYSTEM_ TRUE)
  else()
set(_DEFAULT_USE_SYSTEM_ FALSE)
  endif()
  option(USE_SYSTEM_ "Use system-installed "
${_DEFAULT_USE_SYSTEM_})
  if(USE_SYSTEM_)
find_package( REQUIRED)
  else()
add_subdirectory(externals/)
  endif()
endif()

If it is a hard dependency, just don't offer the
DISABLE_PACKAGE_ option, and always set it to OFF.

I think your proposal and my above use-case should probably be best
implemented in macros/functions and distributed either with CMake or
some CMake modules library project.

My 2c.

Michael
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Integration of manpage installation

[Michael Wild]

On 06/07/2011 03:47 PM, Werner Mahr wrote:
> Eric Noulard wrote:
> 
>>> My suggestion is, to add a new property like man-source-dir or
>>> somehow like that, and all pages in that dir are installed to the
>>> right place if they start with the name of the corresponding
>>> executable.
>  
>> Have a look at the new (in 2.8.4)  GnuInstallDirs.cmake module:
>>
>> http://www.cmake.org/Bug/view.php?id=3976
> 
> This Bug is about Vars for the installation-dirs, I'm thinking about 
> installation-process.
> 
> Usually manpages are named in sources like "cmake.1" and are installed 
> $mandir/1/cmake
> 
> or most often
> 
> $mandir/1/cmake.gz
> 
> So I want to implement functionality to allow the dwevs to just give the 
> place of manpage-sources and let cmake do all the steps:
> 
> Rename from . or .. to 
> 
> 
> compress to .gz (maybe configurable)
> 
> install to $mandir//[.gz] or 
> $mandir///[.gz]
> 
> If $mandir is given directly or configured in a var like your link 
> describes doesn't matter in this case. I don't know about other systems 
> like Linux, so maybe the process is different for other plattforms, but 
> at least in Linux-systems it would be a great help.
> 
> As I started porting amule to cmake I got stuck at exactly that point. 
> Google just pointed out hits where the poster got told to look how 
> others did it, but there's no generic solution. I would prefer to 
> provide such a generic solution instead of reinventing the wheel for 
> such a common task over and over again.
> 

install(FILES cmake.1
  DESTINATION ${CMAKE_INSTALL_FULL_MANDIR}/man1 COMPONENT doc)

If you want gzipping, either leave it to the package generation system
(e.g. dh_installman on Debian and cohorts) or add a custom command to do so.

Michael
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Integration of manpage installation

[Michael Wild]

On 06/07/2011 05:59 PM, Werner Mahr wrote:
> Michael Wild wrote:
> 
>>> Rename from . or .. to
>>> 
> 
>>> install to $mandir//[.gz] or
>>> $mandir///[.gz]
> 
>> install(FILES cmake.1
>>   DESTINATION ${CMAKE_INSTALL_FULL_MANDIR}/man1 COMPONENT doc)
>>
>> If you want gzipping, either leave it to the package generation system
>> (e.g. dh_installman on Debian and cohorts) or add a custom command to
>> do so.
> 
> Gzipping isn't the problem, the problem are these two steps above. With 
> this command no transformation is done.
> 
> amule.1 goes to $mandir/man1/amule.1 instead of $mandir/man1/amule.1
> amule.de.1 goes to $mandir/man1/amule.de.1 $mandir/de/man1/amule.1
> 
> Even worse
> locale.7 would go to $mandir/man1/locale.7 where it definitely not 
> belongs.
> 

foreach(m amule.1 amule.de.1 locale.7)
  get_filename_component(b ${m} NAME_WE)
  get_filename_component(e ${m} EXT)
  if(e MATCHES "(([a-zA-Z_-]+)\\.)?([0-9])")
set(l "${CMAKE_MATCH_2}")
set(s "${CMAKE_MATCH_3}")
  else()
message(SEND_ERROR
  "Failed to parse language and section from manpage name '${m}'")
  endif()
  install(FILES ${m}
DESTINATION "${CMAKE_INSTALL_MANDIR}/${l}/man${s}" COMPONENT doc
RENAME ${b}.${s})
endforeach()


Michael
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Integration of manpage installation

[Michael Wild]

On 06/07/2011 07:40 PM, Werner Mahr wrote:
> Michael Wild wrote:
>  
>> foreach(m amule.1 amule.de.1 locale.7)
>>   get_filename_component(b ${m} NAME_WE)
>>   get_filename_component(e ${m} EXT)
>>   if(e MATCHES "(([a-zA-Z_-]+)\\.)?([0-9])")
>> set(l "${CMAKE_MATCH_2}")
>> set(s "${CMAKE_MATCH_3}")
>>   else()
>> message(SEND_ERROR
>>   "Failed to parse language and section from manpage name '${m}'")
>>   endif()
>>   install(FILES ${m}
>> DESTINATION "${CMAKE_INSTALL_MANDIR}/${l}/man${s}" COMPONENT doc
>> RENAME ${b}.${s})
>> endforeach()
> 
> Unfortunately not:
> 
> CMake Error at docs/man/cmake_install.cmake:38 (FILE):
>   file called with network path DESTINATION.  This does not make sense 
> when
>   using DESTDIR.  Specify local absolute path or remove DESTDIR 
> environment
>   variable.
> 
>   DESTINATION=
> 
>   //man1
> Call Stack (most recent call first):
>   cmake_install.cmake:39 (INCLUDE)

That is a different, unrelated problem.

> 
> Plus there are files out there like:
> 
> svgalib.faq.de.7
> 
> which would raise the error in the code.

Well, then that can be fixed.

> I don't think that writing 
> stuff like this in many different projects is a good idea, that's why I 
> proposed to include it native in cmake.
> 
> ADD_EXECUTABLE(, )
> SET_TARGET_PROPERTIES ( PROPERTIES MAN_SOURCES "docs/man/")
> 
> is much easier to write. Expected behaviour is to install above 
> mentioned sheme docs/man/* to the right places.
> 
> From my point as a dev participating in more than one prjoect it would 
> be a pita to try to understand how they implemented their manpage-
> installation, plus it would slim down many projects lot.
> 

IMHO, sounds an awful lot like DWIM to me, but others might disagree. I
don't think that CMake could satisfy everybody by using such a scheme.
Just my 2c...

Michael
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Automoc in cmake

[Michael Wild]

On 06/08/2011 09:24 PM, Bill Hoffman wrote:
> On 6/8/2011 2:59 PM, Alexander Neundorf wrote:
> 
>>
>> The "two things" are
>> - BSD licensing,  we did that 3 years ago:
>> http://quickgit.kde.org/?p=automoc.git&a=commit&h=78fdba1e2d96bc45512531748ffb770cb1124798
>>
>> -and porting to STL+cmsys, we did that now
>>
>> Beside that, I didn't ask explicitely, but I'm sure without automoc
>> cmake is
>> out of the game for becoming the buildsystem for Qt5 (because in Qt4
>> they do
>> automoc in qmake).
>>
>> Alex
>>
> I think it would be a good idea to have automoc support in CMake.
> 
> -Bill

Although this is not really my call, here my thoughts:

While I share some of the concerns that this is a very specialist tool
of little use in general, but considering the importance of Qt, the
strong coupling between KDE and CMake and finally the possibility of
CMake becoming the QMake replacement, I think this makes a strong case
for an exception here.

So, +1 from me.

Michael
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Adding argument "OPTIONAL" to find_package() and add_subdirectory

[Michael Wild]

On 06/20/2011 07:46 PM, Brad King wrote:
> On 06/20/2011 12:40 PM, Alexander Neundorf wrote:
> 
>> What is the recommended way how to do this with git ?
>>
>> Simply add one more commit which does that or do I have to do something with 
>> rebase --interactive ?
>> How does that play together with the branch I already pushed ? Will this 
>> pushed branch get a new history ?
> 
> As you guessed, interactive rebase is the correct approach.  Since
> you have not merged the topic you are free to overwrite it on the
> topic stage.  The old version of the history will be replaced with
> the new version.  It might feel funny the first time but it is nice
> and easy once you get the idea.  I use it all the time locally to
> clean up and organize a topic into a logical series of changes
> before pushing it out.
> 
> -Brad

For this kind of work, I also like to use StGit. It is similar to Quilt,
but makes full use of Git.

Michael
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Adding argument "OPTIONAL" to find_package() and add_subdirectory

[Michael Wild]

On 06/23/2011 04:11 PM, Brad King wrote:
> On 06/23/2011 09:53 AM, Alexander Neundorf wrote:
>> On Thursday 23 June 2011, Brad King wrote:
>>> On 06/23/2011 05:12 AM, Alexander Neundorf wrote:
> Please put it at the very bottom of the entire
> documentation, just above the note about NO_POLICY_SCOPE.

 Done.
>>>
>>> Thanks.  The topic looks good.  Please merge it to 'next' when
>>> you're ready.
>>
>> Won't this have the effect that it will be in 2.8.5 ?
> 
> No.  We manually select topics from 'next' and merge them to 'master'.
> Only topics in master will be released.
> 
>   http://www.cmake.org/Wiki/CMake/Git#Branches
> 
> -Brad

So, how does that work? Do you look for the merges in 'next' that you
like, and then re-merge them to 'master' directly from the topic-branch?

Something like this?


-- A  I -- master
\   \   \/
 \   \   C --- D -- G -- topic2
  \   \  \
   \   B -- D -- topic1   \
\\ \
 \--- F H -- next

i.e. everything starts at A, 'master' and 'next' being identical. Then,
someone creates 'topic1' and merges it into 'next' (commit F).
Meanwhile, another topic, 'topic2' is created, and also merged into
'next' (commit H). Now, 'topic1' just isn't ready, but 'topic2' is, so
it gets merged into 'master' (commmit I). Is this correct?

Is 'next' kind of your "throw-away" integration branch? Do you rebase it
regularly onto master?

Michael
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Adding argument "OPTIONAL" to find_package() and add_subdirectory

[Michael Wild]

On 06/23/2011 06:02 PM, Brad King wrote:
> On 06/23/2011 10:36 AM, Michael Wild wrote:
>> On 06/23/2011 04:11 PM, Brad King wrote:
>>> We manually select topics from 'next' and merge them to 'master'.
>>> Only topics in master will be released.
>>
>> So, how does that work? Do you look for the merges in 'next' that you
>> like, and then re-merge them to 'master' directly from the topic-branch?
> 
> Yes.  The complete workflow is described generically here:
> 
>   http://public.kitware.com/Wiki/Git/Workflow/Topic
> 
> We use a "topic stage" repository to keep explicit topic branch heads
> that are not in all integration branches:
> 
>   http://public.kitware.com/Wiki/Git/Workflow/Stage
> 
> CMake's topic stage is published here:
> 
>   http://cmake.org/stage/cmake.git
> 
> The set of branches changes regularly as topics are added or finished.
> 
>> Something like this?
>>
>> -- A  I -- master
>> \   \   \/
>>  \   \   C --- D -- G -- topic2
>>   \   \  \
>>\   B -- D -- topic1   \
>> \\ \
>>  \--- F H -- next
> 
> Yes, exactly.
> 
>> i.e. everything starts at A, 'master' and 'next' being identical. Then,
>> someone creates 'topic1' and merges it into 'next' (commit F).
>> Meanwhile, another topic, 'topic2' is created, and also merged into
>> 'next' (commit H). Now, 'topic1' just isn't ready, but 'topic2' is, so
>> it gets merged into 'master' (commmit I). Is this correct?
> 
> Yes.  It gets a little more complicated when there are conflicts:
> 
>   http://public.kitware.com/Wiki/Git/Workflow/Topic/Conflicts
> 
>> Is 'next' kind of your "throw-away" integration branch?
> 
> Yes.  No topics are allowed to see any of the merges into next.  There
> is even a check on the server that disallows topics (or master) to see
> the beginning of next.
> 
>> Do you rebase it regularly onto master?
> 
> So far we haven't rewritten it but the workflow allows that because
> nothing should be based on it.  Currently we have to avoid rewriting
> the branch because some dashboard clients may do just "git pull" to
> update.  Recent CTest versions do a fetch & reset so that they can
> handle upstream rewrites.
> 
> I designed all of the above after reading about Git's own workflow:
> 
>   
> http://git.kernel.org/?p=git/git.git;a=blob;f=Documentation/howto/maintain-git.txt;hb=v1.7.5
> 
> Our "topic stage" takes the place of the maintainer's private repository.
> I designed it to help distribute some of the maintainer's workload among
> developers (and they don't even have to know; it's just part of their
> workflow).
> 
> -Brad

Thanks for the thorough explanation. I have to say, it is very well
thought-through, I'll try to enforce something similar for my projects.
gitworkflows(7) always seemed a bit unwieldy to me, but then it is also
geared towards much larger projects with many more contributors...

Michael
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] [CMake 0012347]: Interface bug

[Michael Wild]

Five times the same useless report, each reported by a different user-id?!

Michael

On 07/16/2011 06:29 AM, Mantis Bug Tracker wrote:
> 
> The following issue has been SUBMITTED. 
> == 
> http://www.cmake.org/Bug/view.php?id=12347 
> == 
> Reported By:ninfar228
> Assigned To:
> == 
> Project:CMake
> Issue ID:   12347
> Category:   CCMake
> Reproducibility:@0@
> Severity:   @0@
> Priority:   @0@
> Status: new
> == 
> Date Submitted: 2011-07-16 00:29 EDT
> Last Modified:  2011-07-16 00:29 EDT
> == 
> Summary:Interface bug
> Description: 
> the cancel button is not shown anywhere!  just http://www.google.com it!
> == 
> 
> Issue History 
> Date ModifiedUsername   FieldChange   
> == 
> 2011-07-16 00:29 ninfar228  New Issue
> ==
> 
> ___
> cmake-developers mailing list
> cmake-developers@cmake.org
> http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] [RFC] golang support

[Michael Wild]

The problem is that add_dependencies() adds only dependencies between
top-level targets, there's nothing that tells CMake to relink the
executable when the library changes. It only ensures that the library is
build *before* the executable. You would need to pass the library output
files to the DEPENDS option of the linking command.

A few more comments:

- Don't use macros unless you have to. Functions have much nicer properties.

- You can simplify finding of the programs to

find_program(GO_COMPILER NAMES 8g 6g 5g
  PATHS ENV GOROOT PATH_SUFFIXES bin
  NO_DEFAULT_PATH)

- There's no 7g, you probably meant 5g.

- You should only search for the "correct" compiler by determining the
architecture you are compiling for first.

- You should probably check the directory properties INCLUDE_DIRECTORIES
and LINK_DIRECTORIES and add them with the -I and -L flags.

- Don't hardcode the .exe suffix. Use ${CMAKE_EXECUTABLE_SUFFIX}
instead. I don't know how it works with the libraries on Windows with
Go, but consider using ${CMAKE_STATIC_LIBRARY_PREFIX} and
${CMAKE_STATIC_LIBRARY_SUFFIX}.

- add_dependencies() accepts multiple dependees, so the loop is unnecessary.

- You might want to take a look at my (unfinished) Vala module for some
inspiration:
http://wildcodes.com/git/CMake/commit/?h=patches/AddValaSupport It is
still a bit buggy (typos, doesn't get all the dependencies right), and I
had a much improved version, but lost it due to a disk failure before I
pushed the changes to the repository...


HTH

Michael

On 08/05/2011 07:08 AM, Colin McCabe wrote:
> Hi all,
> 
> Google Go is a fun language that I've been playing around with.
> http://en.wikipedia.org/wiki/Go_(programming_language)
> 
> I wrote a little cmake file to help me compile Google Go (golang)
> source files using CMake.
> 
> However, it's currently not working as expected. The go executables
> are not rebuilt when the go libraries change.
> 
> ==
> FIND_PROGRAM(GO_COMPILER
> bin/6g.exe
> bin/7g.exe
> bin/8g.exe
> bin/6g
> bin/7g
> bin/8g
> PATHS
> $ENV{GOROOT}
> NO_DEFAULT_PATH
> )
> IF(NOT GO_COMPILER)
> MESSAGE(FATAL_ERROR "Could not find the go compiler")
> ENDIF(NOT GO_COMPILER)
> 
> FIND_PROGRAM(GO_ARCHIVER
> bin/gopack.exe
> bin/gopack
> PATHS
> $ENV{GOROOT}
> NO_DEFAULT_PATH
> )
> IF(NOT GO_ARCHIVER)
> MESSAGE(FATAL_ERROR "Could not find the go packer")
> ENDIF(NOT GO_ARCHIVER)
> 
> FIND_PROGRAM(GO_LINKER
> bin/6l.exe
> bin/7l.exe
> bin/8l.exe
> bin/6l
> bin/7l
> bin/8l
> PATHS
> $ENV{GOROOT}
> NO_DEFAULT_PATH
> )
> IF(NOT GO_LINKER)
> MESSAGE(FATAL_ERROR "Could not find the go linker")
> ENDIF(NOT GO_LINKER)
> 
> MACRO(add_go_exe exefile)
> SET(OBJ_FILE ${CMAKE_CURRENT_BINARY_DIR}/${exefile}.8)
> SET(EXE_FILE ${CMAKE_CURRENT_BINARY_DIR}/${exefile})
> ADD_CUSTOM_COMMAND(OUTPUT ${OBJ_FILE}
> COMMAND ${GO_COMPILER}
> ARGS -I ${CMAKE_CURRENT_BINARY_DIR} -I ${PROJECT_BINARY_DIR}
> -o ${OBJ_FILE} ${ARGN}
> MAIN_DEPENDENCY ${ARGN}
> WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}
> )
> ADD_CUSTOM_COMMAND(OUTPUT ${EXE_FILE}
> COMMAND ${GO_LINKER}
> ARGS -L ${PROJECT_BINARY_DIR} -L ${CMAKE_CURRENT_BINARY_DIR}
> -o ${EXE_FILE} ${OBJ_FILE}
> MAIN_DEPENDENCY ${OBJ_FILE}
> WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}
> )
> ADD_CUSTOM_TARGET(${exefile}.exe ALL DEPENDS ${EXE_FILE})
> ENDMACRO (add_go_exe)
> 
> MACRO(add_go_lib libfile)
> ADD_CUSTOM_COMMAND(OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/${libfile}.8
> COMMAND ${GO_COMPILER}
> ARGS -I ${CMAKE_CURRENT_BINARY_DIR} -I ${PROJECT_BINARY_DIR}
> -o ${CMAKE_CURRENT_BINARY_DIR}/${libfile}.8 ${ARGN}
> MAIN_DEPENDENCY ${ARGN}
> WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}
> )
> ADD_CUSTOM_COMMAND(OUTPUT ${PROJECT_BINARY_DIR}/${libfile}.a
> COMMAND ${GO_ARCHIVER}
> ARGS crg ${PROJECT_BINARY_DIR}/${libfile}.a
> ${CMAKE_CURRENT_BINARY_DIR}/${libfile}.8
> MAIN_DEPENDENCY ${CMAKE_CURRENT_BINARY_DIR}/${libfile}.8
> WORKING_DIRECTORY ${PROJECT_BINARY_DIR}
> )
> ADD_CUSTOM_TARGET(${libfile} ALL DEPENDS
> ${CMAKE_CURRENT_BINARY_DIR}/${libfile}.8
> ${PROJECT_BINARY_DIR}/${libfile}.a)
> ENDMACRO (add_go_lib)
> 
> MACRO(target_link_go_libs exefile)
> FOREACH(libfile ${ARGN})
> ADD_DEPENDENCIES(${exefile}.exe ${libfile})
> ENDFOREACH(libfile)
> ENDMACRO(target_link_go_libs)
> ==
> 
> I'm curious if anyone has any ideas about the best way to fix this.
> Alternately, how difficult would it be to add native support to golang
> in CMake, the same way Fortran, Ada, and D have?
> 
> thanks,
> Colin McCabe
> ___
> cmake-developers mailing list
> cmake-developers@cmake.org
> http://public.kitware.com

Re: [cmake-developers] [RFC] golang support

[Michael Wild]

On 08/05/2011 09:46 AM, Michael Wild wrote:
[...]
> 
> - You might want to take a look at my (unfinished) Vala module for some
> inspiration:
> http://wildcodes.com/git/CMake/commit/?h=patches/AddValaSupport It is
> still a bit buggy (typos, doesn't get all the dependencies right), and I
> had a much improved version, but lost it due to a disk failure before I
> pushed the changes to the repository...
> 

Scratch that, just found a backup. Pushed the changes.

Michael
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] [PATCH 4/7] Make cmLocalGenerator::ConvertToLinkReference virtual

[Michael Wild]

On 09/27/2011 04:00 PM, Rolf Eike Beer wrote:
>> This provides a mechanism for the local generator to override how
>> library search paths are generated.
>> ---
>>  Source/cmLocalGenerator.h |2 +-
>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/Source/cmLocalGenerator.h b/Source/cmLocalGenerator.h
>> index 1f5a26e..69e452b 100644
>> --- a/Source/cmLocalGenerator.h
>> +++ b/Source/cmLocalGenerator.h
>> @@ -369,7 +369,7 @@ protected:
>>std::string FindRelativePathTopBinary();
>>void SetupPathConversions();
>>
>> -  std::string ConvertToLinkReference(std::string const& lib);
>> +  virtual std::string ConvertToLinkReference(std::string const& lib);
>>
>>/** Check whether the native build system supports the given
>>definition.  Issues a warning.  */
> 
> You have not changed this, but I wonder why this function is "std::string
> const&" while the others are usually "const std::string &".
> 
> Eike

This is just a matter of style, both notations are fully equivalent.

Michael

--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] [PATCH 0/7] Preparation for Ninja generator: refactorings, bug fixes

[Michael Wild]

On 09/27/2011 02:19 PM, Brad King wrote:
> On 9/26/2011 11:48 PM, Peter Collingbourne wrote:
>> Now that the Ninja generator is passing all tests on Linux, I have
>> decided to start preparing patches, and I am starting with some
>> refactorings and bug fixes developed in the course of developing the
>> Ninja generator.  Three of the patches were originally by Nicolas
>> Despres, the rest are by myself.
> 
> Fantastic!  Thanks for the well-formatted patch submission.  It was easy
> to review the inline patch series.  I also fetched your prep branch from
> github.  I think we can merge it as soon as the 2.8.6 release is finalized.
> 
> Patches 1-6 look good.  Please expand the commit message in patch 7 to
> elaborate on the specific problems it fixes.  That looks like a real bug
> fix rather than just refactoring.  I guess no one has been using per-config
> link flags.
> 
> Thanks!
> -Brad

Does this fix http://cmake.org/Bug/view.php?id=10552?

Michael
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] [PATCH 0/7] Preparation for Ninja generator: refactorings, bug fixes

[Michael Wild]

On 09/27/2011 05:22 PM, Brad King wrote:
> On 9/27/2011 10:34 AM, Michael Wild wrote:
>> On 09/27/2011 02:19 PM, Brad King wrote:
>>> Please expand the commit message in patch 7 to
>>> elaborate on the specific problems it fixes.  That looks like a real bug
>>> fix rather than just refactoring.  I guess no one has been using
>>> per-config
>>> link flags.
>>
>> Does this fix http://cmake.org/Bug/view.php?id=10552?
> 
> It should fix at least part of it.  As the reporter of that issue
> can you test the patch to see if it fixes the original problem?
> 
> Thanks,
> -Brad

Sorry, my Mac died some months ago, so I'll have to see whether I can
talk my office-mate into testing it. He's in China right now, so it'll
have to wait until later this week when he returns.

Michael
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] slow regex implementation in RegularExpression

[Michael Wild]

On 11/24/2011 12:34 AM, Brad King wrote:
> On 11/23/2011 5:43 PM, Brad King wrote:
>> On 11/23/2011 12:44 PM, Brad King wrote:
>>> However, the above does not need to stand in the way of solving the
>>> problem you're addressing.  We can simply set that goal aside for
>>> now by not exposing TRE in the CMake language anywhere.  Use it
>>> just for cmCTestBuildHandler.
>>
>> but people kept going on "the above" part of the debate ;)
> 
> After some more thought, I've realized that no approach currently
> proposed is practical:
> 
> - cmCTestBuildHandler can use a list of custom regular expressions
>   so we cannot assume all of them will be compatible with TRE
> 
> - As David Cole pointed out there are many places, like CTest's
>   "-R" and "-E" options, that use regular expressions in contexts
>   where we cannot possibly use a policy.  Any attempt to do so in
>   such places would just turn into a second API to set the policy
>   in the local context of the regex.
> 
> - If we add a second API like MATCHES => MATCHES_TRE then we would
>   eventually need to do that in *every* place that offers regex
>   matching.  That would mean alternatives to the above -R and -E
>   options and a lot more.
> 
> - People could write code that passes a regex around in a variable.
>   This would hide from the author of the regex the context in which
>   it will be used, so it is unknown whether it is TRE or traditional.
> 
> I propose we go back to an approach discussed the first time PCRE
> was proposed.  The indication of the type of regex must be in the
> regex itself.  IIRC the proposal was something like
> 
>   REGEX:...# old
>   PCRE:... # PCRE
> 
> Of course that is ambiguous too because the prefixes are valid
> expressions.  Instead we can use a prefix that is not otherwise
> a valid expression.  We can use an idea from Python:
> 
>   http://docs.python.org/library/re.html
> 
> that defines expressions of the form (?...) which are not otherwise
> valid.  In order to avoid conflict with future use of the constructs
> they define, we can use the comment form Python defines:
> 
>  (?#OLD)...   # old
>  (?#TRE)...   # TRE
> 
> This is quite easy to implement.  Just take the currently proposed
> patch that replaces use of cmsys::RegularExpression with the new
> cmFastRegularExpression wrapper (perhaps renamed cmRegularExpression).
> Inside the wrapper look for a leading comment of the above form to
> decide which regex impl to use internally.  Then strip off the prefix
> and pass the rest of the regex to the underlying implementation.
> Once this is done update all the default warning and error regular
> expressions that CTest uses.  Add the (?#TRE) prefix to them.
> 
> This approach will solve the speed problem, give people access to the
> TRE extended features when they want it anywhere CMake already uses
> a regex, has no compatibility problems, is a very narrow second
> interface, and is extensible for future optional regex behavior.
> 
> -Brad

I like that proposal a lot, although I'm afraid it is a bit verbose.
Some of my regexes are already pretty lengthy, pushing the 80-columns limit.

Michael
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] Should a module attempt to find its own dependencies?

[Michael Wild]

On 01/09/2012 03:07 AM, David Cole wrote:
> 
> 
> On Sunday, January 8, 2012, Alexander Neundorf  > wrote:
>> On Sunday 08 January 2012, Stephen Kelly wrote:
>>> Alexander Neundorf wrote:
>>> > On Sunday 08 January 2012, Stephen Kelly wrote:
>>> >> Hi,
>>> >>
>>> >> I don't think I've ever seen a direct answer to this question.
>>> >
>>> > AFAIK, yes, they should.
>>> > FindKDE4Internal.cmake finds Qt, FindPNG.cmake finds zlib.
>>> >
>>> >> Is it something to be decided on a case by case basis? If so, then why
>>> >> is there no general case?
>>> >>
>>> >> I can see a possible reason that it is not solvable in the general
> case
>>> >> because sometimes the behaviour of find_package can be changed by
>>> >> setting variables (eg, one might use QT_USE_QTXMLPATTERNS before
>>> >> finding Qt4).
>>> >>
>>> >> Specifically this comes up for me because I need to know whether Qt5
>>> >> modules should find their own dependencies. That is, should
>>> >>
>>> >> find_package(Qt5Gui)
>>> >>
>>> >> cause
>>> >>
>>> >> find_package(Qt5Core REQUIRED)
>>> >>
>>> >> to be called or not?
>>> >
>>> > I'd say yes.
>>> > Otherwise the imported targets in Qt5Gui will depend on not yet defined
>>> > targets from Qt5Core.
>>> >
>>> > The same way cmake takes care of adding the required additional
> libraries
>>> > to the link line (like adding zlib when linking libpng), it should also
>>> > take care of this, IMO.
>>> >
>>> > You should just have to state
>>> > find_package(Foo)
>>> > and this will get you Foo.
>>>
>>> That implies that
>>>
>>> * Qt5Gui_INCLUDE_DIRS should also contain Qt5Core_INCLUDE_DIRS
>>>
>>> * Qt5Gui_DEFINITIONS should contain Qt5Core_DEFINITIONS
>>>
>>> * Qt5Gui_COMPILE_DEFINITIONS should contain Qt5Core_COMPILE_DEFINITIONS
>>>
>>> Right?
>>
>>
>> Yes, I'd say so.
>> But let's wait also for some opinions from others.
>>
>> Alex
>> --
>>
>> Powered by www.kitware.com 
>>
>> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>>
>> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
>>
> 
> I'd say so too. Waiting for a dissenting opinion... ;-)

Not from me... I fully agree with Alex.

Michael

--

Powered by www.kitware.com

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

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

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

[cmake-developers] License of the dashboard:cmake_common.cmake script

[Michael Wild]

Hi all

I based my dashboard driver script on the one used by CMake
(http://cmake.org/gitweb?p=cmake.git;a=blob;f=cmake_common.cmake;hb=refs/heads/dashboard)
and wonder what it's license is. Is it the usual 3-clause BSD-style license?

Michael
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] License of the dashboard:cmake_common.cmake script

[Michael Wild]

On 01/18/2012 03:16 PM, Brad King wrote:
> On Wed, Jan 18, 2012 at 8:41 AM, Michael Wild  wrote:
>> I based my dashboard driver script on the one used by CMake
>> (http://cmake.org/gitweb?p=cmake.git;a=blob;f=cmake_common.cmake;hb=refs/heads/dashboard)
>> and wonder what it's license is. Is it the usual 3-clause BSD-style license?
> 
> Yes, the notice was simply missing.  I added it:
> 
>   http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fe760baa
> 
> Thanks!
> -Brad

Great, thanks for the fast response!

Michael
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] Documented property IMPORTED_LOCATION does not exist

[Michael Wild]

On 01/24/2012 05:50 AM, Alan W. Irwin wrote:
> The documentation you get from
> 
> cmake --help-full
> 
> refers to the IMPORTED_LOCATION property as one of the more important
> ones set for imported targets.  I have to agree that location is the
> most important property for imported targets, but the name appears to
> be wrong for the documentation of this property!
> 
> After screwing around for a while trying to use the above
> property for my imported targets, I discovered (by guessing) that the
> name of a property that actually does give the location information is
> IMPORT_LOCATION, not IMPORTED_LOCATION.  For what it is worth,
> IMPORT_LOCATION works for an imported library, and I haven't tried
> this on imported executables. (By the way, LOCATION works as well, but
> that appears from the documentation to be a left-over from CMake 2.4
> which is why I tried to get IMPORTED_LOCATION to work and when that
> failed, switched to the currently undocumentated IMPORT_LOCATION.)
> 
> I find IMPORTED_LOCATION is mentioned in the following
> places in the cmake-2.8.6 source tree:
> 
> software@raven> find cmake-2.8.6 -print0 -type f \
> |xargs -0 grep -l IMPORTED_LOCATION
> cmake-2.8.6/ChangeLog.txt
> cmake-2.8.6/Modules/FindQt4.cmake
> cmake-2.8.6/Tests/ExportImport/Import/A/CMakeLists.txt
> cmake-2.8.6/Tests/SimpleInstall/CMakeLists.txt
> cmake-2.8.6/Tests/SimpleInstallS2/CMakeLists.txt
> cmake-2.8.6/Source/cmTarget.cxx
> cmake-2.8.6/Source/cmAddExecutableCommand.h
> cmake-2.8.6/Source/cmAddLibraryCommand.h
> cmake-2.8.6/Source/cmExportBuildFileGenerator.cxx
> cmake-2.8.6/Source/cmExportInstallFileGenerator.cxx
> 
> A similar search for IMPORT_LOCATION found nothing at all!
> 
> However, I spot-checked cmake-2.8.6/Source/cmTarget.cxx, and all those
> mentions of IMPORTED_LOCATION appear to be documentation strings
> rather than executable code, and I was unable to find why
> IMPORTED_LOCATION does not work for me while IMPORT_LOCATION does. So
> this needs someone who is familiar with the CMake code to figure out
> what the actual problem is here, and to decide whether a fix to the
> documentation strings is all that is required or whether some deeper
> change needs to be made.
> 
> Alan

IMPORTED_LOCATION works just fine for me. Also IMPORT_LOCATION, as you
call it, is not referenced once in the whole CMake source, while
IMPORTED_LOCATION is, and not only as a documentation string as you
claim. Try

$ git grep '"IMPORTED_LOCATION"'

So it must be something else you're doing wrong.

Michael


--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] Documented property IMPORTED_LOCATION does not exist

[Michael Wild]

On 01/25/2012 12:25 AM, Alan W. Irwin wrote:
> On 2012-01-24 06:28+0100 Michael Wild wrote:
> 
>> On 01/24/2012 05:50 AM, Alan W. Irwin wrote:
>>> The documentation you get from
>>>
>>> cmake --help-full
>>>
>>> refers to the IMPORTED_LOCATION property as one of the more important
>>> ones set for imported targets.  I have to agree that location is the
>>> most important property for imported targets, but the name appears to
>>> be wrong for the documentation of this property!
>>>
>>> After screwing around for a while trying to use the above
>>> property for my imported targets, I discovered (by guessing) that the
>>> name of a property that actually does give the location information is
>>> IMPORT_LOCATION, not IMPORTED_LOCATION.  For what it is worth,
>>> IMPORT_LOCATION works for an imported library, and I haven't tried
>>> this on imported executables. (By the way, LOCATION works as well, but
>>> that appears from the documentation to be a left-over from CMake 2.4
>>> which is why I tried to get IMPORTED_LOCATION to work and when that
>>> failed, switched to the currently undocumentated IMPORT_LOCATION.)
>>>
>>> I find IMPORTED_LOCATION is mentioned in the following
>>> places in the cmake-2.8.6 source tree:
>>>
>>> software@raven> find cmake-2.8.6 -print0 -type f \
>>> |xargs -0 grep -l IMPORTED_LOCATION
>>> cmake-2.8.6/ChangeLog.txt
>>> cmake-2.8.6/Modules/FindQt4.cmake
>>> cmake-2.8.6/Tests/ExportImport/Import/A/CMakeLists.txt
>>> cmake-2.8.6/Tests/SimpleInstall/CMakeLists.txt
>>> cmake-2.8.6/Tests/SimpleInstallS2/CMakeLists.txt
>>> cmake-2.8.6/Source/cmTarget.cxx
>>> cmake-2.8.6/Source/cmAddExecutableCommand.h
>>> cmake-2.8.6/Source/cmAddLibraryCommand.h
>>> cmake-2.8.6/Source/cmExportBuildFileGenerator.cxx
>>> cmake-2.8.6/Source/cmExportInstallFileGenerator.cxx
>>>
>>> A similar search for IMPORT_LOCATION found nothing at all!
>>>
>>> However, I spot-checked cmake-2.8.6/Source/cmTarget.cxx, and all those
>>> mentions of IMPORTED_LOCATION appear to be documentation strings
>>> rather than executable code, and I was unable to find why
>>> IMPORTED_LOCATION does not work for me while IMPORT_LOCATION does. So
>>> this needs someone who is familiar with the CMake code to figure out
>>> what the actual problem is here, and to decide whether a fix to the
>>> documentation strings is all that is required or whether some deeper
>>> change needs to be made.
>>>
>>> Alan
>>
>> IMPORTED_LOCATION works just fine for me. Also IMPORT_LOCATION, as you
>> call it, is not referenced once in the whole CMake source, while
>> IMPORTED_LOCATION is, and not only as a documentation string as you
>> claim.
> 
> Hi Michael:
> 
> Thanks for your response.
> 
> Since you cannot verify the issue, then the most likely reason is
> there is some difference between your and my CMake version, minimum
> CMake version (which affects policy decisions), and hardware/software
> platform. Could you be more specific about those constraints in your
> case?
> 
> Just to be sure I was reporting a clean result, I started with a
> fresh bootstrap build and install of CMake-2.8.7 that I did on my Debian
> Squeeze platform. I then built and installed PLplot (which
> specifies cmake_minimum_required(VERSION 2.8.2 FATAL_ERROR) from
> scratch using that version of cmake.
> 
> I have attached the resulting export module files that are installed
> as a result of that PLplot install.
> 
> I then checked imported target properties with the following CMake test
> script
> (which is also attached for convenience).
> 
> project(test_export NONE)
> cmake_minimum_required(VERSION 2.8.2 FATAL_ERROR)
> set(CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR} )
> include(export_plplot OPTIONAL RESULT_VARIABLE IF_PLOT)
> if(IF_PLOT)
>   get_target_property(test_loc1 _plplotcmodule IMPORT_LOCATION)
>   message(STATUS "IMPORT_LOCATION = ${test_loc1}")
>   get_target_property(test_loc2 _plplotcmodule IMPORTED_LOCATION)
>   message(STATUS "IMPORTED_LOCATION = ${test_loc2}")
> else(IF_PLOT)
>   message(WARNING "IF_PLOT = ${IF_PLOT}")
> endif(IF_PLOT)
> 
> And here was the result when cmake was invoked from a sub-directory
> of the one containing the above CMakeLists.txt and the export files.
> 
> software@raven> cmake ..
> -- IMPORT_LOCATION =
> /home/software/plplot_svn/installcmake/lib/python2.6/site-packages/_plplotcmodule.so
> 
> -- IMPOR

Re: [cmake-developers] How to handle package Config.cmake files with dependencies ?

[Michael Wild]

On 02/27/2012 09:15 PM, Alexander Neundorf wrote:
> Hi,
> 
> I think find_package in Config mode might still need some more work.
> 
> When the FooConfig.cmake has been found, Foo_FOUND is set to TRUE:
> 
>  // Set a variable marking whether the package was found.
>   std::string foundVar = this->Name;
>   foundVar += "_FOUND";
> 
> 
> This means it is true in all cases that the Config.cmake file has been found 
> (and the version was compatible).
> 
> Now I have to questions:
> 
> 
> * how to handle COMPONENTS ?
> 
> 
> If a package is requested with COMPONENTS, these should be considered for 
> setting Foo_FOUND:
> find_package(Foo REQUIRED COMPONENTS A B C)
> should only succeed if A, B and C are found.
> 
> This is how I would expect COMPONENTS to be handled in a FindFoo.cmake:
> (a) all components are searched by the Find-module, and each per-component 
> X_Y_FOUND is set accordingly
> 
> (b) there is a package-specific default subset of these components which have 
> to be found to make the package found, i.e. FOO_FOUND=TRUE
> 
> (c) by adding COMPONENTS to the find_package() call, these components are 
> added to the set of components which have to be found to make FOO_FOUND=TRUE
> 
> (d) if REQUIRED is used and FOO_FOUND is false, it errors out
> 

I like that proposal. I'm also quite unhappy with how components are
handled in config-mode.

> 
> 
> * how to handle dependencies ?
> 
> 
> Let's say the exported targets of Foo link against other imported/exported 
> targets. So that the imported targets work properly, the targets for the 
> libraries it depends on must have been found and imported before.
> Where should this 
> find_package(Bar)
> be done ?
> In FooConfig.cmake ?
> This would be possible only if Bar can be found in Config mode, because 
> otherwise Foo cannot rely on FindBar.cmake being available.
> 
> For Find-modules, it is clear that a Find-module should also find all its 
> dependencies.
> For a Config file I'm not sure about it. Shouldn't this be only a source of 
> information, purely declarative, and not initiate searching other packages ?


I think current best practice is to call find_package(Bar) inside the
FooConfig.cmake. If the FindBar.cmake is contained in CMake,
everything's fine (possibly, you need a cmake_minimum_required()),
otherwise Foo should install FindBar.cmake alongside FooConfig.cmake.

Michael
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] FinQt4/UseQt4 / module QtWebKit isn't found with Qt 4.8.1 even if installed

[Michael Wild]

On 05/16/2012 06:51 AM, Adrien Guinet wrote:
> Hello everyone,
> 
> It seems that, in Qt 4.8.1 (at least in the Debian packages), the QtWebKit
> module isn't shipped in a separated .so (libQtWebKit.so).
> Thus, this makes FindQt4.cmake fails to find the QtWebkit modules, beucase
> a module is considered found when both its libraries files and directories
> are found. As a consequence, include directories are not set if the
> QT_USE_QTWEBKIT variable is set to TRUE (for instance), and code fails to
> compile.
> 
> I don't know if this is an issue with the Debian packages of Qt (last
> packages in sid as of today), or if Qt decided to build QtWebkit within
> QtGui.
> 
> Attached to this mail is a temporary patch (well, an ugly *hack* actually)
> that I am using (against FindQt4.cmake) :
> 
> Thanks for any help or comments about this !
> 
> Regards,
> 

Do you have the libqtwebkit-dev package installed?

Michael
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] what happened to cmake users forum?

[Michael Wild]

On 08/30/2012 03:44 PM, Skippy VonDrake wrote:
> I remember belonging to a mailing list meant for general questions
> from cmake users.
> Where does on go no when the have a problem/question just using cmake?
> This site: http://public.kitware.com/mailman/listinfo/dart
> just lists "cmake-developers" and "cmake-commits".
> Or does this list include user questions?
> From looking at the archives it looks like its meant for developers
> working on enhancing/fixing cmake.
> 

Here: http://public.kitware.com/mailman/listinfo/cmake

HTH

Michael
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] Documentation 'latest' url

[Michael Wild]

On 09/21/2012 04:36 PM, Stephen Kelly wrote:
> 
> Hi,
> 
> This page has links for various versions of cmake:
> 
> http://www.cmake.org/cmake/help/documentation.html
> 
> Would it be possible to get a 'latest' url too, such as 
> 
> http://www.cmake.org/cmake/help/latest/cmake.html
> 
> It would make more sense to link to such a url from the Qt documentation.
> 
> Thanks,
> 
> Steve.

Excavating this oldish, unanswered post:

+1 from me! It certainly would help linking to the up-to-date docs from
the Wiki...

Michael

--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] Documentation 'latest' url

[Michael Wild]

On Thu, Apr 4, 2013 at 2:33 PM, Brad King  wrote:

> On 04/04/2013 12:12 AM, Michael Wild wrote:
> > On 09/21/2012 04:36 PM, Stephen Kelly wrote:
> >> This page has links for various versions of cmake:
> >>
> >> http://www.cmake.org/cmake/help/documentation.html
> >>
> >> Would it be possible to get a 'latest' url too, such as
> >>
> >> http://www.cmake.org/cmake/help/latest/cmake.html
> >>
> >> It would make more sense to link to such a url from the Qt
> documentation.
> >
> > Excavating this oldish, unanswered post:
> >
> > +1 from me! It certainly would help linking to the up-to-date docs from
> > the Wiki...
>
> The problem with unversioned URLs is that people link to them based
> on their current content.  When the content changes in the next version
> some of the links become nonsense.  I don't know how many times I've
> seen links to a version control web viewer posted to say "look at
> line 10 here", and of course line 10 has long since changed because
> they didn't use a URL that specifies the repository version.
>
> What we need is an unversioned URL that automatically redirects to the
> latest versioned URL.  That way someone following a link that is
> intended to be unversioned will get a versioned URL in their browser.
> Unfortunately server-side redirects cause some browsers to strip the
> "#tag" part of the URLs, and client-side redirects require Javascript.
>
> -Brad
>

Thanks for the details. Not worth the trouble, then.

Michael
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] Safe source list GLOBs

[Michael Wild]

On 29.05.2013 22:59, Matthew Woehlke wrote:
> On 2013-05-28 21:23, Wojciech Knapik wrote:
>> On Fri, May 24, 2013 at 11:21:57AM -0400, Matthew Woehlke wrote:
[...]
> 
>> I do understand the distinction between calling cmake and make and I
>> understood from the start when variables are evaluated and such, but I
>> just assumed that globs are propagated to the generated build system,
>> because a) why not ? b) what's the point of globs if they aren't ?
>>
>> Imagine my surprise...
> 
> Actually, I find your surprise very surprising. You say you understand
> that setting and using variables happens at configure time. Well,
> file(GLOB) populates a variable... so why would you expect those
> variables to be somehow magically special?

Also, very astonishing to me is the fact that after apparently finding
file(GLOB) in the documentation, you clearly didn't read the whole
paragraph. It's right there:

>> We do not recommend using  GLOB  to collect  a list of source files
>> from your source tree.  If no CMakeLists.txt file changes when a
>> source is added or removed then the generated build system cannot
>> know when to ask CMake to regenerate.

As you are so fond of clear violations: You failed to RTFM...
(http://en.wikipedia.org/wiki/Rtfm)

Besides, you seem to be very sure that CMake is the *only* tool that
prefers explicit source file listing. Have you ever used any of the
popular IDE's? Visual Studio? Xcode? Eclipse? They all create explicit
list of files in their projects.

What are the (not so serious) pros and cons of GLOB, even if it worked
the way you think it should?

Pro:
* laziness

Con:
* laziness
* extremely error prone:
  - picks up scratch files
  - works for you but breaks for others because you forgot to commit a
file
  - breaks for you because the other dude forgot to commit his file
* makes it unnecessarily difficult to exclude files from the build
  - temporarily: for testing (you'd need to move the file away and then
remember to move it back; error prone again)
  - permanently: dependent on the platform, configuration, enabled
capabilities etc. And using #ifdef's for this is bad because you
still invoke the compiler and waste time to just compile an "empty"
file.
* when reading the build system code, you have to switch context in
  order to determine the files included in the build.


On the other hand, initially creating and then maintaining an explicit
list of files is easy. Initially I usually create the list of files like
this using vim:

:r !cd $(dirname %); ls **/*.{c,cpp}; ls **/*.{h,hpp}


Michael
--

Powered by www.kitware.com

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

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

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