John Drescher | 1 Jul 01:24 2011
Picon

Re: CMake Wiki spammed

On Thu, Jun 30, 2011 at 6:27 PM, Moreland, Kenneth <kmorel@...> wrote:
> It looks like the CMake Wiki recently got spammed.  I see several links were
> recently added that do not belong (head lice treatment?).  Even more
> annoying, it looks like the spammer removed some links that do belong there.

It's a mess. I was trying to back out of this but there are multiple
SPAM edits in between a few good edits. Ahmed appears to have done
most of the spamming.

John
_______________________________________________
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 | 1 Jul 01:30 2011

Re: CMake Wiki spammed

I have forwarded this to our IT team... Hopefully it's not too hard to recover from for them.

Thanks,
David


On Thu, Jun 30, 2011 at 7:24 PM, John Drescher <drescherjm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
On Thu, Jun 30, 2011 at 6:27 PM, Moreland, Kenneth <kmorel <at> sandia.gov> wrote:
> It looks like the CMake Wiki recently got spammed.  I see several links were
> recently added that do not belong (head lice treatment?).  Even more
> annoying, it looks like the spammer removed some links that do belong there.

It's a mess. I was trying to back out of this but there are multiple
SPAM edits in between a few good edits. Ahmed appears to have done
most of the spamming.

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

_______________________________________________
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
John Drescher | 1 Jul 01:34 2011
Picon

Re: CMake Wiki spammed

I think I fixed it.

John

On Thu, Jun 30, 2011 at 7:30 PM, David Cole <david.cole@...> wrote:
> I have forwarded this to our IT team... Hopefully it's not too hard to
> recover from for them.
>
> Thanks,
> David
>
>
> On Thu, Jun 30, 2011 at 7:24 PM, John Drescher <drescherjm@...> wrote:
>>
>> On Thu, Jun 30, 2011 at 6:27 PM, Moreland, Kenneth <kmorel@...>
>> wrote:
>> > It looks like the CMake Wiki recently got spammed.  I see several links
>> > were
>> > recently added that do not belong (head lice treatment?).  Even more
>> > annoying, it looks like the spammer removed some links that do belong
>> > there.
>>
>> It's a mess. I was trying to back out of this but there are multiple
>> SPAM edits in between a few good edits. Ahmed appears to have done
>> most of the spamming.
>>
>> John
>> _______________________________________________
>> 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
>
>

--

-- 
John M. Drescher
_______________________________________________
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

邓尧 | 1 Jul 03:14 2011
Picon

One source file, different arch

Hi,

I'm new to CMake. My project is a little different from the projects found in the tutorials. I have to compile some of the source files into two different archs(32-bit & 64-bit). It's like the following:
  Given 4 source files: A.c, B.c, C.c, D.c, I need to compile a 32-bit executable with source file A.c, B.c and C.c, I also need to compile a 64-bit executable with source file A.c B.c and D.c.
How to write the CMake script in this situation?

Thanks

-Yao

_______________________________________________
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
Bill Hoffman | 1 Jul 04:03 2011

Re: Parallel make & custom command

On 6/30/2011 5:23 PM, Alan W. Irwin wrote:
> On 2011-06-30 22:15+0200 Alexander Neundorf wrote:
>
>> On Wednesday 29 June 2011, Marcel Loose wrote:
>> ...
>>> After I had posted my question I realized that this issue has come up
>>> quite recently on the mailing list in a thread that I started -- see
>>>
http://www.mail-archive.com/cmake-wChDC6UyXvPYtjvyW6yDsg <at> public.gmane.org/msg36362.html.
Although the
>>> original question was related to building mulitple targets in parallel,
>>> Michael Hertling showed that CMake inherently has problems with parallel
>>> builds when custom targets/commands come into play.
>>
>> Really ?
>> We use a lot of custom commands in KDE, all the time, everywhere, and
>> people
>> build KDE on big build clusters, i.e. very parallel, without problems.
>>
>> Maybe there are problems when multiple targets depend on the same
>> generated
>> file, but I think the "cmake inherently has problems with parallel
>> builds when
>> custom targets/commands come into play." is wrong in this very generic
>> way.
>
> I agree with Alex here. It is always possible, of course, to set up
> custom commands and custom targets properly so that parallel builds
> work correctly. The trick is to avoid two or more targets depending
> on the same custom command. So bug 0012311 should just be closed
> since that is based on a misunderstanding of how to properly set up
> custom commands and targets.
>
> The above rule of thumb is easy to implement for simple build systems,
> but for complex build systems it is easy to make file or target
> dependency mistakes so that parallel builds do not work correctly.
> This is the number-one issue I have had difficulty with for our PLplot
> CMake-based build system because that system has lots of custom
> commands and a complex web of file and target dependencies that
> changes each time we add new build or test features.
>
> To help with the general difficulty of getting dependencies right,
> would it be possible to implement a CMake change so that for a given
> flag (say --check-dependencies) the cmake application issued warnings
> for file and target dependency issues that would cause problems for
> parallel builds for a given CMake-based build system? That would help
> a lot to solve this topic that keeps coming up again and again on this
> list and also make existing CMake-based build systems much easier to
> maintain.
>
> Assuming such a change was implemented, then the standard FAQ response
> to this topic would then boil down to "run cmake with the
> --check-dependencies flag to find out the dependency issues you have
> to solve before you can reliably run a parallel build."
>

If we had a magic flag that did --check-dependencies we would just auto 
add the depends.  The problem is these depends can be hard to find. 
Some of them can not even be found until everything has been built or at 
least all files have been generated, and all source files have been 
scanned for depend information.  CMake saves the depend generation of 
source files to build time.  So, at CMake time we don't even know which 
source files include which other source files.   This stuff can be 
nested as well.  You could generated foo.c which includes bar.h which is 
also generated right after car.h which is included by car.c all of which 
might be in different targets and directories.  So, although all things 
are possible, this one is very hard to do....

-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:
http://www.cmake.org/mailman/listinfo/cmake

Michael Hertling | 1 Jul 07:57 2011
Picon

Re: Enabling C99 in CMake

On 06/26/2011 04:12 PM, Owen Shepherd wrote:
> On 25/06/2011 07:30, "Michael Hertling" <mhertling@...> wrote:
> 
>> On 06/24/2011 04:16 PM, Owen Shepherd wrote:
>>> I think the appropriate solution here is a project-specific dialect
>>> flag -
>>> perhaps one taking options in the GNU format since it seems most
>>> familiar.
>>> One could perhaps generalise this further - a file-specific dialect flag
>>> which defaults to the value of the project-specific flag
>>
>> If there are individual compilers for C89/C99, and a projects needs a
>> C99 one, any dialect flags - project/directory/target/file specific -
>> would be of no use, wouldn't they? Rather, one must specify the C99
>> compiler if it isn't found automatically by CMake during the initial
>> configuration, and the project might consider to check the compiler's
>> C99 capabilities.
> 
> Sorry - I should have said property rather than flag. That is, something
> along the lines of
> 	set_target_properties(the_target PROPERTIES C_DIALECT C99)
> Or
> 	set_source_files_properties(myfile.c PROPERTIES C_DIALECT C99)
> 
> (I'm not entirely sure here whether the source file property should be
> C_DIALECT or just DIALECT. The language, after all, should be unambiguous
> at this point)
> 
> It would then be the responsibility of the Cmake machinery to choose the
> right compiler and set it up for building code with the given dialect.

This would require to configure the entire project *before* the compiler
is chosen, and this means that constructs like

IF(CMAKE_C_COMPILER_ID STREQUAL ...)

or

IF(CMAKE_COMPILER_IS_GNUC)

wouldn't work anymore. Of course, they're quite useful and necessary if
one wants to enable compiler-specific features, so the compiler must be
chosen at the very beginning. Moreover, IMO, it's absolutely inevitable
that the responsibility for choosing a suitable compiler rests on the
user. The fact that CMake usually finds a suitable one automatically
- although common and very convenient - should be considered as the
exception rather than the rule, at least in multi-compiler setups.

Regards,

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://www.cmake.org/mailman/listinfo/cmake

Michael Hertling | 1 Jul 08:12 2011
Picon

Re: Enabling C99 in CMake

On 06/27/2011 06:34 PM, Todd Gamblin wrote:
> On Jun 24, 2011, at 11:30 PM, Michael Hertling wrote:
> 
>> On 06/23/2011 06:20 PM, Jed Brown wrote:
>>> On Thu, Jun 23, 2011 at 17:50, Michael Hertling
<mhertling@...> wrote:
>>>
>>>> You need to use a C99 compiler for your project
>>>
>>>
>>> This is already a problem. C99 introduces new keywords (e.g. restrict) and
>>> removes implicit int. It is entirely possible for part of a project to
>>> include C89-conforming legacy code that is not valid C99. The use of C99 or
>>> C89 should be a file- and directory-level property.
>>
>> That's a really good point and could indeed be very well addressed by
>> a possibility for a project to enable language dialects per directory/
>> target/file as Todd has asked for in his initial posting.
> 
> Yep -- After reading all the responses, think my suggestion was insufficient.  Just having a variable for
the compiler flags isn't enough.  Also, I really like the dialects approach here.  This has the potential to
take care of not only C99, but also C++ *and* Fortran.  The Fortran support in CMake could really use this
kind of thing, as it would be very helpful to know if particular Fortran compilers support F90, F77, F08, etc.
> 
>> In order to
>> achieve this in a platform/compiler-independent manner, take a look at
>> the attached dialects.patch file, a diff against the Modules directory
>> of CMake 2.8.4. It is not meant as a production-ready solution, but as
>> as proof of concept, and it's restricted to the GNU C compiler, though
>> it should be easily applicable to the other compilers known by CMake.
> 
> Thanks for making this!
> 
>> First of all, the new Compiler/LanguageDialects.cmake file provides a
>> function __language_dialects() which accepts a language and a paired
>> list of arguments denoting each supported language dialect followed by
>> the flags to enable it. The function sets up the variable CMAKE_<LANG>_
>> DIALECTS_INIT containing the list of dialects, and for each dialect a
>> variable CMAKE_<LANG>_DIALECT_≤DIALECT>_INIT containing the respective
>> flags. The Compiler/GNU-C.cmake file is enhanced to - exemplary - call
>>
>>> __language_dialects(C C90 "-std=c90" C89 "-std=c89" C99 "-std=c99" C9X "-std=c9x" C1X "-std=c1x"
ANSI "-ansi")
> 
> This looks great.  One question is what to do with things like gnu99.  This is C99 plus GNU extensions.  I ask
because the GNU compiler separates this from regular C99, while other compilers like XL don't.  If you run
xlc -qlanglvl=c99, it supports inline assembly, but if you run gcc -std=c99, it does not.  You have to run
with std=gnu99.
> 
> I *suspect* that most people will prefer gnu99 by default, as the lenient mode is the default for both gcc
and xlc, but I could be conjecturing too far here.
> 
> My suggestion would be to have an option like "CMAKE_STRICT_C_DIALECT=TRUE" that says to also turn off
support for compiler-specific extensions if possible, e.g.:
> 	gcc:		-std=c99
> 	xlc:		-qnoasm -qlanglvl=c99
> 
> and stick to the standard, but prefer the more lenient mode by default e.g.:
> 	gcc:		-std=gnu99
> 	xlc:		-qlanglvl=c99

IMO, such a dialect strictness flag would be problematic due to the
expectations the users may have and the undesired effects that may
occur. E.g., does strict C99 mean that C89 constructs are rejected?
For this, one needs to pass "-pedantic-errors" or the like to GCC,
but I'd have objections to enable such a flag automatically since
the user might prefer a non-pedantic behavior elsewhere. Further-
more, what does strict C99 mean for compilers which don't fully
support this standard, like MSVC as Hendrik has remarked in the
meantime? Finally, the more flags one includes in the CMAKE_C_
DIALECT_C99 variable, the higher is the probability to cause
contraries to the user's intention. Suppose one wants to have
strict C99 *plus* inline assembly with XL C; one might initially
configure the project with "CFLAGS=-qasm cmake ..." which makes the
"-qasm" switch appear on the command line before the "-qnoasm" one
enabled by CMAKE_C_DIALECT_C99 via the COMPILE_FLAGS property, e.g.,
so inline assembly is finally disabled, though requested explicitly.
With __language_dialects(), one could edit the dialect flags in the
cache taking "-q[no]asm" into account before the configuration starts.

The approach with __language_dialects() is meant as a simple method to
pass simple options to the compiler in order to express the need for a
specific language dialect via a simple compiler-independent interface,
but one should not aim at a more fine-grained control; regarding the
different compilers with their countless command line options, this
would be nearly impossible, even on the limited realm of language
dialects. BTW, with GNU C, one would call __language_dialects()
including "GNU99 -std=gnu99" and the like, of course, since the
user certainly expects that GNU compilers support GNU dialects.

>> This turns out to be a simple and promising approach that
>>
>> - provides the developers with platform/compiler-independent variables
>>  to check if the compiler accepts a certain dialect and to enable it,
> 
> Yes.  This is great.
> 
>> - places the compiler-specific dialect flags in the compiler-specific
>>  files in the Modules/Compiler directory where they obviously belong,
> 
> Excellent.
> 
>> - doesn't require complicated modifications in the Modules directory.
> 
> Also great.
> 
>> If you like this idea, feel free to add it to the feature request Todd
>> has filed in the meantime. However, while this approach is independent
>> of the dialects a compiler actually supports, be aware that mixed C89/
>> C90 projects to be built with CMake need *one* compiler which masters
>> C89 *and* C99, and that's not guaranteed for all of them.
> 
> I'm not sure what a good way around this would be, given the current internals of CMake.  I would personally
like to see CMake support multiple compilers like this for other reasons (mixing cross-compiled and
non-cross-compiled builds) but I don't think that will happen in the near future and I'm not sure what a
clean way to support it would be.

As I've written in my reply to Owen's posting, one might use a wrapper
script which scans its arguments for a home-brewed dialect switch and
accordingly invokes different compilers, but this approach certainly
bears limitations and is only good for project-specific solutions, at
most site-specific ones. For the moment, mixed-dialect projects seem
to be built best with a multi-dialect compiler, and any compiler which
does not support all required dialects should be rejected as unsuitable.
CMAKE_<LANG>_DIALECT_≤DIALECT> could be quite helpful in this regard, too.

Regards,

Michael

>>> It's also horrible to encumber the poor user just trying to build your
>>> project with needing to know whether it is written in C99 or whatever else,
>>> nor with how to make their compiler deliver that dialect.
>>
>> Once the CMake-detected or user-specified compiler isn't suitable for
>> the project, the user is in charge of choosing another one, and this
>> might happen quite quickly; it's sufficient that the compiler is not
>> in the PATH or unusually named. Then, the user must know whether the
>> project needs a C and/or C++ and/or Fortran compiler, and where it's
>> located. In such a situation, the need to know that a C99 compiler
>> is required does not make any further difference to the user, IMO.
> 
> This seems in line with the current level of knowledge effort required to build a CMake project.  There is an
effort to get things right automatically, but if you want a specific compiler and things can't be guessed,
you're on your own.  I agree on this one.
> 
>> In order not to be misunderstood: Of course, I appreciate measures
>> making the user's life easier, but I don't believe that choosing a
>> suitable compiler via the CC environment variable is something that
>> means an excessive demand for anyone.
> 
> I agree with this, too.  I just think that it's possible to do better in this case.  It's these kinds of
convenience features that make CMake a pleasant build system.  Thanks for putting the patch together -- I
think we should replace my initial feature request with this because your patch is far more comprehensive.
> 
> -Todd
_______________________________________________
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 Hertling | 1 Jul 08:14 2011
Picon

Re: Enabling C99 in CMake

On 06/27/2011 07:07 PM, Rolf Eike Beer wrote:
> Michael Hertling wrote:
> 
>> SET_SOURCE_FILES_PROPERTIES(${CMAKE_BINARY_DIR}/c89.c
>>     PROPERTIES COMPILE_FLAGS ${CMAKE_C_DIALECT_C89})
>> SET_SOURCE_FILES_PROPERTIES(${CMAKE_BINARY_DIR}/c99.c
>>     PROPERTIES COMPILE_FLAGS ${CMAKE_C_DIALECT_C99})
>> ADD_LIBRARY(c89 c89.c)
>> ADD_LIBRARY(c99 c99.c)
>>
>> It issues the supported C dialects and the contents of the associated
>> dialect variables, and the c89.c and c99.c source files are compiled
>> with the correct flags. Of course, the CMAKE_C_DIALECT_≤DIALECT>
>> variables can also be appended to the CMAKE_C_FLAGS[_<CONFIG>]
>> variables instead of the COMPILE_FLAGS source file property.
> 
> With a bit of thinking I would suggest a slightly different way. Don't add 
> specific compiler flags for that source file. Tell CMake that this sourcefile uses 
> a specific language dialect:
> 
> SET_SOURCE_FILES_PROPERTIES(${CMAKE_BINARY_DIR}/c89.c
>      PROPERTIES LANGUAGE_DIALECT C89)
> 
> Then let CMake internally do the fiddling with the compile flags. This would 
> have a few benefits:
> 
> -if e.g. the language flags need to be passed first to the compiler CMake can 
> assure this
> -colliding flags can be detected by the underlying implementation
> -if we ever get support for e.g. 2 different C compilers things like the Sun 
> (was it Sun? Too lazy to look up) compilers can be supported as CMake would 
> just call the right compiler binary
> -this can easily change in any direction later if someone decides the 
> underlying implementation needs a change
> 
> Well, basically all points target in the same direction, no? It seperates the 
> switch logic from the user and allow greater flexibility in the implementation. 
> With the expense that probably some C++ code of CMake needs to be touched.
> 
> Eike

Currently, one can add a new compiler - a real one as well as a wrapper
script - without rebuilding CMake itself, and that's highly convenient.
Is it feasible to implement such a, say, flag management along with the
necessary knowlegde base, i.e. information about which flags to add/re-
move/modify/reorder, in pure CMake code? Do you intent to include flags
concerning dialect strictness? E.g., GCC with "-std=c99" accepts legacy
C89 constructs, but doesn't recognize inline assembly introduced by the
"asm" keyword; other compilers might handle this differently. So, does
the C99 dialect property means strict C99, lenient C99 w.r.t. C89, C99
with common extensions etc., and will the decision be enforced? Pardon
for these critical questions, but I think they - and possibly others -
should be considered when contemplating a comprehensive management of
language dialect flags. The numerous compilers with their vast number
of flags - even just the dialect-related ones - make me believe that
this would be a nearly impossible undertaking. The approach with the
__language_dialects() function, in contrast, aims at a quite simple
mechanism doing simple things via a simple interface and is easy to
implement without narrowing the user's freedom more than necessary.
Additionally, it allows to query the basic dialect capabilities of
the compiler in charge and to edit the dialect flags in the cache
similar to the configuration flags CMAKE_<LANG>_FLAGS_≤CONFIG>.

Regards,

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://www.cmake.org/mailman/listinfo/cmake

Veijo Änäkäinen | 1 Jul 08:59 2011
Picon

ExternalProject, Install command

Sorry about possible double sending, I guess my first mail to this list didn't come through.

I try to cross compile ppp as an external project. The install command is

INSTALL_COMMAND
      make BINDIR=${EXTERNAL_PREFIX}/bin MANDIR=${EXTERNAL_PREFIX}/man INSTALL='/usr/bin/install --strip-program=${STRIP_

PROGRAM}' install-progs


The install step fails with next error message

[  0%] Performing install step for 'ppp'
make: unrecognized option '--strip-program=/opt/crosstool/gcc-3.4.5-glibc-2.3.6/armv5b-softfloat-linux/bin/armv5b-softfloat-linux-strip''

Is there any way to set a white space separated value for the make inside the ExternalProject or should I use a separate script? Running the build step directly in a shell works fine.

Thanks advanced

-Veijo
_______________________________________________
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
owen.arnold | 1 Jul 09:52 2011
Picon

CPACK NSIS Destination Directory

Hi,

 

I’ve been using CPack to generate NSIS installers. On my Windows 7 64-bit development platform this works perfectly. When I started building the release and generating the packages on our build server (also Windows 7 64-bit) things aren’t quite as smooth. The installer is generated fine, but the installer page containing the “Destination Directory” fails to prefix the path with C:/Program Files (x86), so instead of C:/Program Files(x86)/{{Project}} I’m presented with /{{Project}}. Comparing the generated Project.nsi files between my development environment and the production build environment, I notice that PROGRAMFILES var is not used at all in the latter, but is in the former to construct INSTALLDIR.

 

The only difference between my development environment and the production build environment (as far as I can tell) is that my development is done on a physical machine and the production machine is a VM. Might this have something to do with PROGRAMFILES not being written into the nsis script? Does anyone have any other suggestions about what might be causing this?

 

Thanks in advance,

 

Owen.


--
Scanned by iCritical.


_______________________________________________
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

Gmane