Clifford Yapp | 1 Sep 06:27 2011
Picon

Re: CMake --debug-trycompile option breaking tests

On Wed, Aug 31, 2011 at 2:14 PM, Bill Hoffman <bill.hoffman@...> wrote:
>
> It would make a mess if you created a sub-dir per test.  There would be lots
> and lots of sub-dirs in some projects.

Personally I would expect that, and be OK with it, as long as the
directory names corresponded to the test in question - is the creation
of large numbers of dirs a performance concern?

Cheers,
CY
_______________________________________________
Powered by www.kitware.com

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

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

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

Michael Wild | 1 Sep 06:29 2011
Picon

Re: Problem and proposed solution with cmake -E rename across devices

On Wed 31 Aug 2011 11:26:19 PM CEST, David Cole wrote:
> On Wed, Aug 31, 2011 at 5:12 PM, Clinton Stimpson <clinton@...> wrote:
>> On Wednesday, August 31, 2011 10:30:22 am David Cole wrote:
>>> On Wed, Aug 31, 2011 at 11:49 AM, David Cole <david.cole@...> wrote:
>>>> The cmake -E rename command is documented to work only when src and
>>>> dst are on the same volume:
>>>>
>>>> If you run "cmake -E" with no other args, the rename command is
>>>> documented as:
>>>>
>>>>  rename oldname newname    - rename a file or directory (on one volume)
>>>>
>>>> I think doing a copy as a fallback is a reasonable thing, but I think
>>>> it's on your side of the fence. CMake properly returns an error and
>>>> tells you "can't do that rename operation" and then it should be uo to
>>>> you to make a copy if that's what you want.
>>>>
>>>> Others may want to do something else if rename cannot be done. I don't
>>>> think we should add code that says CMake will do a copy if rename
>>>> fails...
>>>>
>>>> On Tue, Aug 30, 2011 at 3:21 PM, Clifford Yapp
<cliffyapp@...> wrote:
>>>>> We've run into an issue with cmake -E rename where the rename fails
>>>>> due to rename() throwing EXDEV when done between devices (different
>>>>> partitions, nfs to local, etc).  Erik Greenwald has investigated and
>>>>> has proposed a fix to allow cmake -E rename to succeed across devices
>>>>> - if possible we'd like to get this or some related fix included,
>>>>> since this is a real-world build environment situation for us:
>>>>>
(Continue reading)

Alan W. Irwin | 1 Sep 11:38 2011
Picon
Picon

Visualizing all build-system options

I was just replying to an acquaintance who was e-mailing me about CMake
configuration when I realized that CMake configuration options
which are only available depending on how other configuration
options are set could be analyzed/displayed using graph theory
(from a 5-minute study of graph theory from reading the first
paragraph of the Wikipedia article on that :-) ).

I looked for a graphviz output file option for this in the cmake
documentation and only found the --graphviz option which will
"Generate a graphviz input file that will contain all the library and
executable dependencies in the project." I used that for PLplot once.
It worked and gave a pretty impressive visual demonstration of all the
complicated and numerous PLplot dependencies.  I wasn't surprised by
any of those detailed relationships because I have them pretty much
memorized, but such information would be a definite help to someone
just getting up to speed with the PLplot build system (or any
CMake-based build system)

Could something similar be done for the dependencies between CMake
options?  I think that would be quite useful (especially if it
included the documentation of the options) for further graphviz
analysis and display of the
relationships between the totality of all the CMake options for a
given build system.  The problem with using cmake-gui for this task
(or the equivalent cmake + looking at the resulting CMakeCache.txt
file) is you only see the first layer of possible configurations as
opposed to the totality of options you could visualize with a graphviz
file.

Moving to a related topic, if you run cmake with no -D options in an
(Continue reading)

Bill Hoffman | 1 Sep 15:00 2011

Re: CMake --debug-trycompile option breaking tests

On 9/1/2011 12:27 AM, Clifford Yapp wrote:
> On Wed, Aug 31, 2011 at 2:14 PM, Bill
Hoffman<bill.hoffman@...>  wrote:
>>
>> It would make a mess if you created a sub-dir per test.  There would be lots
>> and lots of sub-dirs in some projects.
>
> Personally I would expect that, and be OK with it, as long as the
> directory names corresponded to the test in question - is the creation
> of large numbers of dirs a performance concern?
>
> Cheers,
> CY
>
I guess I have two concerns.

1. Windows is not good with lots of files/dirs (can be slow)

2. Naming and tracking these dirs maybe difficult giving the current api 
to try-compile/try-run.

If someone wants to try and implement this, it would most likely be a 
good thing if it can be done.  It would require lots of testing with big 
existing cmake builds like KDE,ParaView, ITK.

That said given the current API, you could have a project that does this 
in the cmake language today.  You just could not use some of the 
standard macros.

-Bill
(Continue reading)

aaron.meadows | 1 Sep 17:29 2011

Re: Bug #12189

Hi David,

I've updated the bug with a patch which adds a test to check that defining _SBCS does set CharacterSet to 0
(Single Byte Character Set).  I checked that it works when _SBCS is set and fails when _SBCS is not defined.

I looked for where the _UNICODE option is documented, thinking to document _SBCS there, but was unable to
find it in the documentation.  If you want to point me to the right location to add documentation, I'm happy
to write some. (I can write some for _UNICODE as well, if you like.)

Aaron Meadows

-----Original Message-----
From: David Cole [mailto:david.cole@...] 
Sent: Wednesday, August 31, 2011 1:04 PM
To: Meadows, Aaron C.
Cc: cmake@...
Subject: Re: [CMake] Bug #12189

The CMake/Tests/CMakeLists.txt file lists most of the tests that execute on our dashboards.

The directories under CMake/Tests are all the existing test source trees. If you want to modify one of the
existing tests to have an "_SBCS" target compile definition, I'd start by looking at "Simple" or "COnly"
as a simple basis for a new test.

Or you may find another one where the code that's compiled and tested is compatible with "_SBCS".

You may want to conditionalize it with code like:
if (CMAKE_GENERATOR MATCHES "Visual Studio") .... or ....
if (MSVC)

(Continue reading)

don la dieu | 1 Sep 17:47 2011
Picon

Re: CMake FindBLAS and FindLAPACK patches

That was intentional. .dll Should already be in CMAKE_FIND_LIBRARY_SUFFIXES on WIN32.

Since your commits haven't hit git/gitweb yet I'm not sure what you didn't commit.

As far as the ACML changes go, the file globbing is way too greedy, and breaks if more than one ACML or ACML-GPU
package is installed. ACML-GPU can be found when you want ACML and vice versa. So, that clearly needs to
change. Also, in the check_fortran_libraries() for ACML you're try trying to search the the
multithreaded library (libacml_mp) when you need to search the single threaded library (libacml). And,
in ACML-GPU you also search the multithreaded library (libacml_mp) which doesn't exist in the ACML-GPU
package provided by AMD. See http://goo.gl/fQKq6 and http://goo.gl/2qCeW. So, clearly those fixes
need to be in there.

Don

On Sep 1, 2011, at 3:02 AM, Alexey Ozeritsky wrote:

> Hello,
> 
> I've commited all the changes except ACML.
> 
> Please check your patches more careful next time:
> 
> -      set(CMAKE_FIND_LIBRARY_SUFFIXES ".lib;.dll")
> +      set(CMAKE_FIND_LIBRARY_SUFFIXES .lib ${CMAKE_FIND_LIBRRAY_SUFFIXES})
> .......................................................................................................^^^^^^
> 
> 
> On Sat, Aug 27, 2011 at 9:21 PM, don la dieu <nega@...> wrote:
>> Hi Alexey-
>> 
(Continue reading)

don la dieu | 1 Sep 23:00 2011
Picon

Re: CMake FindBLAS and FindLAPACK patches


On Sep 1, 2011, at 12:00 PM, Alexey Ozeritsky wrote:

> On Thu, Sep 1, 2011 at 7:47 PM, don la dieu <nega@...> wrote:
>> That was intentional. .dll Should already be in CMAKE_FIND_LIBRARY_SUFFIXES on WIN32.
> 
> Yes, it should already be in CMAKE_FIND_LIBRARY_SUFFIXES but not in
> CMAKE_FIND_LIBRRAY_SUFFIXES as in your patch :)
> 

Ah spelling my one true nemesis! :)

I was wondering... would make more sense (post 2.8.6) to break ACML out into it's own module, and change
FindBLAS and FindLAPACK so they called FindACML? It seems like most of the complexity in FindBLAS is now
mostly ACML related.

don
_______________________________________________
Powered by www.kitware.com

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

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

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

David Cole | 2 Sep 00:00 2011

Re: Visualizing all build-system options

Sounds like a great research project for somebody. Would be cool to
see CMake options visualized for some larger projects...

Not sure of its feasibility in terms of completeness, however. I'm
sure you could come up with something rudimentary that seems to work
for some cases.

There are some cases that you will simply never reach, even though the
code is in there.

For example, consider what happens when you have this code:

if(WIN32)
  option(SOME_WIN32_SPECIFIC_OPTION ...)
endif()

And then you run your tool on your Linux box. I don't care how many
iterations you do, you're simply never going to see the platform
specific option.

Also, in order to aim for completeness, you'd need to deal with
potential code like this:

if(optA AND optB AND optC AND optD OR NOT (optE AND optF))
  option(REALLY_WELL_HIDDEN_OPTION ...)
endif()

Basically, the "inner" option will only be triggered in a very
specific set of true-false values of all the "outer" options...

(Continue reading)

Alan W. Irwin | 2 Sep 02:48 2011
Picon
Picon

Re: Visualizing all build-system options

On 2011-09-01 18:00-0400 David Cole wrote:

> Sounds like a great research project for somebody. Would be cool to
> see CMake options visualized for some larger projects...
>
> Not sure of its feasibility in terms of completeness, however. I'm
> sure you could come up with something rudimentary that seems to work
> for some cases.
>
> There are some cases that you will simply never reach, even though the
> code is in there.
>
> For example, consider what happens when you have this code:
>
> if(WIN32)
>  option(SOME_WIN32_SPECIFIC_OPTION ...)
> endif()
>
> And then you run your tool on your Linux box. I don't care how many
> iterations you do, you're simply never going to see the platform
> specific option.
>
> Also, in order to aim for completeness, you'd need to deal with
> potential code like this:
>
> if(optA AND optB AND optC AND optD OR NOT (optE AND optF))
>  option(REALLY_WELL_HIDDEN_OPTION ...)
> endif()
>
> Basically, the "inner" option will only be triggered in a very
(Continue reading)

Bill Hoffman | 2 Sep 04:10 2011

Re: Visualizing all build-system options

On 9/1/2011 8:48 PM, Alan W. Irwin wrote:

> Yeah, it is fun to speculate about something new like this that would
> be of considerable benefit to help a project's developers and users
> visualize the complete set of options and their dependencies for their
> project's build system. Unfortunately I don't have sufficient
> knowledge of the CMake code base (or C++ for that matter) to do this
> myself, and I assume nobody at Kitware has spare time to do such an
> implementation. However, maybe someone else here or perhaps a GSOC
> student next year might be interested in fleshing this idea out into
> something useful.
>

I guess at the end of the day what you are talking about is a static 
code analysis tool for the CMake language.  Those tools look at all 
possible branches of code and try to detect errors.  Although not 
impossible, this would not be something that could be hacked out 
quickly.  As a rough order, I would put this at several man months of 
effort.  Maybe a GSOC...

-Bill

_______________________________________________
Powered by www.kitware.com

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

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

Follow this link to subscribe/unsubscribe:
(Continue reading)


Gmane