Re: [cmake-developers] Welcome to June, time for the next release candidate
Am Montag, 4. Juni 2012 um 17:13:26, schrieb David Cole david.c...@kitware.com We are preparing to build CMake 2.8.9, release candidate one, in the next few days (or possibly as late as next week). Is there any pending/outstanding work that anybody thinks is critical for inclusion in CMake 2.8.9? (I don't want to trigger a flurry of activity by sending this out... but I suppose it's better to have it before we decide to cut rc1 than after. ;-) Thanks, David There is still the problem that created debian packages are not working with dpkg. System: ubuntu 12.04, 64 bit. Cmake: created with -DCMAKE_USE_SYSTEM_LIBARCHIVE:BOOL=ON The following list of commands: # make package # create xyzz.deb # ar rv xyzz.deb data.tar.gz # tar ztvf data.tgz /dev/null tar: Ignoring unknown extended header keyword `SCHILY.fflags' tar: Ignoring unknown extended header keyword `SCHILY.fflags' tar: Ignoring unknown extended header keyword `SCHILY.fflags' tar: Ignoring unknown extended header keyword `SCHILY.fflags' I already proposed a patch in the users list (using archive_write_set_format_gnutar() instead of archive_write_set_format_pax_restricted() in file Source/cmArchiveWrite.cxx) which make things work OK on this system. Kornel signature.asc Description: This is a digitally signed message part. -- 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] [CMake 0013270]: Remove temporary debug message for ASM compiler id
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13270
==
Reported By:raspy
Assigned To:
==
Project:CMake
Issue ID: 13270
Category: (No Category)
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2012-06-05 04:05 EDT
Last Modified: 2012-06-05 04:05 EDT
==
Summary:Remove temporary debug message for ASM compiler id
Description:
This is regarding commit 9071b8b87f0e63f10f1f77949246c1b4241cfb6c.
Please remove this temporary message. After over a year in code it is no
longer temporary and its output is confusing users and is pure garbage in build
log. We use TI assembler so it barfs out many times before it is detected.
Please also do not put such temporary debug messages in official release
builds. It is confusing users and builders.
Steps to Reproduce:
Set CMAKE_C_COMPILER in a toolchain file to cl6x and then set CMAKE_ASM_COMPILER
to ${CMAKE_C_COMPILER}. Upon ASM configuration it barfs out all kind of compiler
versions and usages.
Additional Information:
Commit 4b40d4297aa7b984e9b5fa905cdee21960ec4f8a changed behavior for assembler
(which I consider a breaking change when connected to this faulty commit
9071b8b87f0e63f10f1f77949246c1b4241cfb6c).
In cmake 2.8.8 (and 2.8.6 at least, but probably somewhere around 2.8.4/5) when
CMAKE_ASM_COMPILER is not set it is taken from CMAKE_C_COMPILER (this is
4b40d4297aa7b984e9b5fa905cdee21960ec4f8a - a good thing). This is the only way
to avoid this faulty behavior of 9071b8b87f0e63f10f1f77949246c1b4241cfb6c and to
keep output silent when detecting ASM compiler id, so I need to remove setting
CMAKE_ASM_COMPILER(_INIT)? from toolchain file. This however will no longer work
with cmake 2.8.3 which does not have behavior from
4b40d4297aa7b984e9b5fa905cdee21960ec4f8a and it default to /usr/bin/as in such
situation.
==
Issue History
Date ModifiedUsername FieldChange
==
2012-06-05 04:05 raspy New Issue
==
--
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] Welcome to June, time for the next release candidate
Stephen Kelly wrote: David Cole wrote: We are preparing to build CMake 2.8.9, release candidate one, in the next few days (or possibly as late as next week). Is there any pending/outstanding work that anybody thinks is critical for inclusion in CMake 2.8.9? I'd very much like the POSITION_INDEPENDENT_CODE topic to be part of it. (I don't want to trigger a flurry of activity by sending this out... but I suppose it's better to have it before we decide to cut rc1 than after. ;-) Yury did some work on export-sets: http://thread.gmane.org/gmane.comp.kde.devel.buildsystem/7257/focus=7274 Currently it just moves export-sets to a dedicated class, so it can be merged if there are no objections. This change would simplify adding additional logic to install(EXPORT ...). But I don't think it's 'done' enough for inclusion yet unfortunately. The existing tests pass, but new ones are needed. Hopefully we can get it ready early in the next cycle. The problem is that I have a few deadlines in June: 2 grant applications have deadlines on 15th, and one on 20th... I'll try to find some time for cmake, but I'm not sure... -- Yury G. Kudryashov, mailto: ur...@mccme.ru -- 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] Welcome to June, time for the next release candidate
2012/6/5 Kornel Benko kor...@lyx.org: Am Montag, 4. Juni 2012 um 17:13:26, schrieb David Cole david.c...@kitware.com We are preparing to build CMake 2.8.9, release candidate one, in the next few days (or possibly as late as next week). Is there any pending/outstanding work that anybody thinks is critical for inclusion in CMake 2.8.9? (I don't want to trigger a flurry of activity by sending this out... but I suppose it's better to have it before we decide to cut rc1 than after. ;-) Thanks, David There is still the problem that created debian packages are not working with dpkg. System: ubuntu 12.04, 64 bit. Cmake: created with -DCMAKE_USE_SYSTEM_LIBARCHIVE:BOOL=ON The following list of commands: # make package # create xyzz.deb # ar rv xyzz.deb data.tar.gz # tar ztvf data.tgz /dev/null tar: Ignoring unknown extended header keyword `SCHILY.fflags' tar: Ignoring unknown extended header keyword `SCHILY.fflags' tar: Ignoring unknown extended header keyword `SCHILY.fflags' tar: Ignoring unknown extended header keyword `SCHILY.fflags' I already proposed a patch in the users list (using archive_write_set_format_gnutar() Discussion is in this thread: http://www.cmake.org/pipermail/cmake/2012-May/050483.html instead of archive_write_set_format_pax_restricted() in file Source/cmArchiveWrite.cxx) which make things work OK on this system. Hi Kornel, Like I said in the previous thread, we simply cannot switch to gnutar, it will potentially break many other systems. Moreover when you compiled the very same CMake using the shipped-in cmlibarchive you didn't get the error. So the issue is an interaction between system provided libarchive and CMake, did try to contact Ubuntu packager about that? -- Erk Le gouvernement représentatif n'est pas la démocratie -- http://www.le-message.org -- 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] Welcome to June, time for the next release candidate
2012/6/4 David Cole david.c...@kitware.com: We are preparing to build CMake 2.8.9, release candidate one, in the next few days (or possibly as late as next week). Is there any pending/outstanding work that anybody thinks is critical for inclusion in CMake 2.8.9? Critical, not really but that one has been waiting in my stack for a long time: (in fact longer than the initial bug report) http://public.kitware.com/Bug/view.php?id=12997 I may not be able to finish (un-pushed) work before next week but if I have a chance to push the first set of clean-up that would be great. (I don't want to trigger a flurry of activity by sending this out... but I suppose it's better to have it before we decide to cut rc1 than after. ;-) -- Erk Le gouvernement représentatif n'est pas la démocratie -- http://www.le-message.org -- 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] Welcome to June, time for the next release candidate
2012/6/4 David Cole david.c...@kitware.com: We are preparing to build CMake 2.8.9, release candidate one, in the next few days (or possibly as late as next week). Is there any pending/outstanding work that anybody thinks is critical for inclusion in CMake 2.8.9? Could you take this one: http://public.kitware.com/Bug/view.php?id=13248 (I don't want to trigger a flurry of activity by sending this out... but I suppose it's better to have it before we decide to cut rc1 than after. ;-) -- Erk Le gouvernement représentatif n'est pas la démocratie -- http://www.le-message.org -- 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] Welcome to June, time for the next release candidate
Yury G. Kudryashov wrote: Stephen Kelly wrote: David Cole wrote: We are preparing to build CMake 2.8.9, release candidate one, in the next few days (or possibly as late as next week). Is there any pending/outstanding work that anybody thinks is critical for inclusion in CMake 2.8.9? I'd very much like the POSITION_INDEPENDENT_CODE topic to be part of it. (I don't want to trigger a flurry of activity by sending this out... but I suppose it's better to have it before we decide to cut rc1 than after. ;-) Yury did some work on export-sets: http://thread.gmane.org/gmane.comp.kde.devel.buildsystem/7257/focus=7274 Currently it just moves export-sets to a dedicated class, so it can be merged if there are no objections. This change would simplify adding additional logic to install(EXPORT ...). But I don't think it's 'done' enough for inclusion yet unfortunately. The existing tests pass, but new ones are needed. Hopefully we can get it ready early in the next cycle. The problem is that I have a few deadlines in June: 2 grant applications have deadlines on 15th, and one on 20th... I'll try to find some time for cmake, but I'm not sure... I don't think there's any need to rush the cmake feature, and there's no need to get the refactoring in without the feature. Let's keep your current work and aim to get it finished for 2.8.10. Thanks, Steve. -- 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] Welcome to June, time for the next release candidate
Am Dienstag, 5. Juni 2012 um 10:11:40, schrieb Eric Noulard eric.noul...@gmail.com I already proposed a patch in the users list (using archive_write_set_format_gnutar() Discussion is in this thread: http://www.cmake.org/pipermail/cmake/2012-May/050483.html instead of archive_write_set_format_pax_restricted() in file Source/cmArchiveWrite.cxx) which make things work OK on this system. Hi Kornel, Like I said in the previous thread, we simply cannot switch to gnutar, it will potentially break many other systems. OK, I understood the hesitation. Moreover when you compiled the very same CMake using the shipped-in cmlibarchive you didn't get the error. So the issue is an interaction between system provided libarchive and CMake, did try to contact Ubuntu packager about that? You mean, I should press the ubuntu packager to use built-in libarchive, instead of using the the approved brand new libarchive version already there? What should I expect as an answer from them? My opinion is: this libarchive will (sooner or later) find it's way to other platforms as well, and also in cmake's own sources. We already reacted once (changing archive_write_set_format_ustar() to archive_write_set_format_pax_restricted()). Never mind, I did not want to be importunate ... Kornel signature.asc Description: This is a digitally signed message part. -- 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] ninja failing CompileCommandOutput
On Tue, Jun 5, 2012 at 5:07 AM, Manuel Klimek kli...@google.com wrote: From taking a very high level look it seems to me like the parser probably needs fixing on Windows Okay, thanks! -Brad -- 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] Welcome to June, time for the next release candidate
Am Dienstag, 5. Juni 2012 um 08:37:37, schrieb Brad King brad.k...@kitware.com On Tue, Jun 5, 2012 at 8:17 AM, Eric Noulard eric.noul...@gmail.com wrote: 2012/6/5 Kornel Benko kor...@lyx.org: Somebody shall dive into the build process of the libarchive Ubuntu package and see **why** it breaks the CMake build while using cmlibarchive does not. This is the proper action. What version of libarchive is used from the system? The builtin cmlibarchive in CMake 2.8.8 is libarchive 3.0.2, from svn rev 4051, now Git commit 28267d8f: https://github.com/libarchive/libarchive/tree/28267d8f/ plus some portability fixes. On ubuntu 12.04 it is package libarchive12, version 3.0.3-6ubuntu1. Dont know what, if anything, they changed. This may-be a usage error on CMake side (and I'll try to help to fix it) but this may well be a mistake on libarchive/Ubuntu side as well. [snip] Yes but this action was widening the compatibility. pax_restricted -- gnutar may be narrowing it. This was discussed here: http://www.cmake.org/Bug/view.php?id=11958 Yes, this is very alike to what I see here. but many archive portability concerns were lifted by updating to a libarchive that included this: https://github.com/libarchive/libarchive/commit/de60ddd0 Still the SHILY.fflags were not handled ... The issue was resolved without changing formats by a fix suggested by a libarchive maintainer: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e8558efa If there are extended headers that dpkg doesn't support then we need to know why they appear in the first place and which ones can be cleared. -Brad OK. Kornel signature.asc Description: This is a digitally signed message part. -- 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] Adding logic to CMake for -fPIE and -fPIC
On 06/05/2012 11:40 AM, Stephen Kelly wrote: http://open.cdash.org/testDetails.php?test=148807497build=2335525 I tried outputting the OUTPUT resulting from the try_compile, but that does not seem to actually create the output as expected, even though the releveant commit is being tested (http://cmake.org/gitweb?p=cmake.git;a=commit;h=84d29a5358e4fa01583e2aef1e8e8097e187045f ). Can someone with access to that box find out what is going on? CMakeError.log contains: cc1plus: error: unrecognized option `-fPIE' It is a very old OS X: $ sw_vers ProductName:Mac OS X ProductVersion: 10.3.9 BuildVersion: 7W98 $ g++ --version g++ (GCC) 3.3 20030304 (Apple Computer, Inc. build 1666) and so probably doesn't understand PIE. -Brad -- 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] [CMake 0013271]: is_file_executable() from GetPrerequisites.cmake erroneously returns 0 for universal binaries (MacOSX)
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13271
==
Reported By:recryn
Assigned To:
==
Project:CMake
Issue ID: 13271
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2012-06-05 18:01 CEST
Last Modified: 2012-06-05 18:01 CEST
==
Summary:is_file_executable() from GetPrerequisites.cmake
erroneously returns 0 for universal binaries (MacOSX)
Description:
On UNIX is_file_executable() executes the tool 'file' and then compares the
returned string with executable: if(${file_ov} MATCHES executable)
However, on MacOSX, there are several 'file' tools available (macports, fink)
which do not share the same output format. Most notably, the output string does
not always match executable if the file is a universal binary. Here are some
possible output strings of 'file' for three different executables on a Mac:
Mach-O executable i386
Mach-O 64-bit executable
Mach-O fat file with 2 architectures
'file /bin/ls' results just in:
/bin/ls: Mach-O fat file with 2 architectures
Note, that a library would be reported as: Mach-O 64-bit dynamically linked
shared library. So matching Mach-O is no good either.
Ideally is_file_executable() would call 'otool -hv' on APPLE and match the
result with EXECUTE, e.g.:
otool -hv /bin/ls
/bin/ls:
Mach header
magic cputype cpusubtype capsfiletype ncmds sizeofcmds flags
MH_MAGIC_64 X86_64ALL LIB64 EXECUTE13 1928 NOUNDEFS
DYLDLINK TWOLEVEL
Steps to Reproduce:
1. Install 'file' from macports:
port install file
2. Prepend macports binary dir (/opt/local/bin) to PATH
3. With a project that uses fixup_bundle:
cmake -DCMAKE_OSX_ARCHITECTURES=x86_64;i386
make
cpack -G Bundle --verbose
[...]
CPack Verbose: libs=''
CPack Verbose: dirs=''
CPack Verbose: warning: *NOT* handled - not .app dir, not executable file...
CMake Error at /opt/local/share/cmake-2.8/Modules/MyBundleUtilities.cmake:723
(message):
error: fixup_bundle: not a valid bundle
Call Stack (most recent call first):
/tmp/trunk/build/cmake/dist/cmake_install.cmake:38 (fixup_bundle)
/tmp/trunk/build/cmake_install.cmake:36 (INCLUDE)
Additional Information:
Patch attached.
==
Issue History
Date ModifiedUsername FieldChange
==
2012-06-05 18:01 recryn New Issue
2012-06-05 18:01 recryn File Added: GetPrerequisites.cmake.diff
==
--
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] libarchive and SCHILY.fflags (was: Welcome to June, time for the next release candidate)
On 06/05/2012 08:57 AM, Kornel Benko wrote: The builtin cmlibarchive in CMake 2.8.8 is libarchive 3.0.2, from svn rev 4051, now Git commit 28267d8f: On ubuntu 12.04 it is package libarchive12, version 3.0.3-6ubuntu1. Can you provide a simple script that reproduces a bad tarball using cmake -E tar when CMake is built against that libarchive, and a test to know if it is bad? If I can reproduce it I can bisect libarchive history. I don't have Ubuntu 12.04 but I do have dpkg. Thanks, -Brad -- 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] Adding logic to CMake for -fPIE and -fPIC
Brad King wrote: On 06/05/2012 11:54 AM, Stephen Kelly wrote: I can add a try_compile for -fPIE on APPLE (though I wonder if it would work), but still, I expect to see something like that in the OUTPUT variable from check_cxx_source_compiles... The OUTPUT variable is internal to the macro and not documented as holding anything when the call returns. A quick glance doesn't tell me why the value isn't leaking out as an implementation detail though. You can't try_compile inside a platform file. I'm not sure I'm trying to? It's too early in the init process because the platform files are needed to generate inside the try_compile. You would have to run your own execute_process and invoke the compiler directly. I suggest checking the compiler version rather than testing the flag. Just checking CMAKE_C_COMPILER_VERSION might be enough in this case. Do you mean in the tests, or do you mean the POSITION_INDEPENDENT_CODE feature should be disabled for older GCC? Thanks, Steve. -- 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] Adding logic to CMake for -fPIE and -fPIC
On 06/05/2012 01:23 PM, Stephen Kelly wrote:
Brad King wrote:
You can't try_compile inside a platform file.
I'm not sure I'm trying to?
I thought you meant you would add the try_compile to the platform file
to decide whether to report -fPIE.
Do you mean in the tests, or do you mean the POSITION_INDEPENDENT_CODE
feature should be disabled for older GCC?
I mean that
set(CMAKE_${lang}_COMPILE_OPTIONS_PIE -fPIE)
should not be done if the compiler does not have -fPIE.
Therefore Modules/Compiler/GNU.cmake needs to test the
compiler version to decide whether -fPIE is available.
Likely other toolchains will need similar checks.
-Brad
--
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] Adding logic to CMake for -fPIE and -fPIC
Brad King wrote:
On 06/05/2012 01:23 PM, Stephen Kelly wrote:
Brad King wrote:
You can't try_compile inside a platform file.
I'm not sure I'm trying to?
I thought you meant you would add the try_compile to the platform file
to decide whether to report -fPIE.
Do you mean in the tests, or do you mean the POSITION_INDEPENDENT_CODE
feature should be disabled for older GCC?
I mean that
set(CMAKE_${lang}_COMPILE_OPTIONS_PIE -fPIE)
should not be done if the compiler does not have -fPIE.
Therefore Modules/Compiler/GNU.cmake needs to test the
compiler version to decide whether -fPIE is available.
I see. Done for GNU.cmake now at least.
Likely other toolchains will need similar checks.
We'll have to deal with those as they come I guess.
Thanks,
Steve.
--
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] libarchive and SCHILY.fflags (was: Welcome to June, time for the next release candidate)
Am Dienstag, 5. Juni 2012 um 13:19:31, schrieb Brad King brad.k...@kitware.com On 06/05/2012 08:57 AM, Kornel Benko wrote: The builtin cmlibarchive in CMake 2.8.8 is libarchive 3.0.2, from svn rev 4051, now Git commit 28267d8f: On ubuntu 12.04 it is package libarchive12, version 3.0.3-6ubuntu1. Can you provide a simple script that reproduces a bad tarball using cmake -E tar when CMake is built against that libarchive, and a test to know if it is bad? If I can reproduce it I can bisect libarchive history. I don't have Ubuntu 12.04 but I do have dpkg. Thanks, -Brad It is really not so easy. I have a directory, which produces such a tar file. Even if I remove all files from that dir, the created tar is bad. It looks, like it would depend on initial number of entries (in my case 528). Maybe, if there are more than 128 ... have to check Ok, I created a dir with 340 entries. (330 entries was not enough). Kornel data.tgz Description: application/compressed-tar signature.asc Description: This is a digitally signed message part. -- 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] libarchive and SCHILY.fflags
Am Dienstag, 5. Juni 2012 um 15:35:15, schrieb Brad King brad.k...@kitware.com On 06/05/2012 01:19 PM, Brad King wrote: On 06/05/2012 08:57 AM, Kornel Benko wrote: The builtin cmlibarchive in CMake 2.8.8 is libarchive 3.0.2, from svn rev 4051, now Git commit 28267d8f: On ubuntu 12.04 it is package libarchive12, version 3.0.3-6ubuntu1. Can you provide a simple script that reproduces a bad tarball using cmake -E tar when CMake is built against that libarchive, and a test to know if it is bad? If I can reproduce it I can bisect libarchive history. I don't have Ubuntu 12.04 but I do have dpkg. I'd still like a test case so I can reproduce the problem locally. However, there were very few changes between the two versions of libarchive, at least upstream: $ git rev-list --count 28267d8..v3.0.3 18 The only one that looks even remotely like it could affect the pax output is this: https://github.com/libarchive/libarchive/commit/bc523371 -Brad Maybe this version (3.0.2) is erroneous too. The last working version on ubuntu 11.10 was libarchive1_2.8.4-1ubuntu0.11.10.1_amd64.deb Kornel signature.asc Description: This is a digitally signed message part. -- 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] [CMake 0013273]: From g++: sorry: semantics of inline function static data `...' are wrong in hashtable.hxx
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13273 == Reported By:Daniel R. Gomez Assigned To: == Project:CMake Issue ID: 13273 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2012-06-05 16:13 EDT Last Modified: 2012-06-05 16:13 EDT == Summary:From g++: sorry: semantics of inline function static data `...' are wrong in hashtable.hxx Description: I see this warning when building CMake from git nightly with g++ 2.9-aix51-020209 on an AIX 5.3 system: CMake-build/Source/cmsys/hashtable.hxx: In function `const long unsigned int *cmsys::get_stl_prime_list ()': CMake-build/Source/cmsys/hashtable.hxx:399: warning: sorry: semantics of inline function static data `const long unsigned int _stl_prime_list[31]' are wrong (you'll wind up with multiple copies) CMake-build/Source/cmsys/hashtable.hxx:399: warning: you can work around this by removing the initializer (Details at http://open.cdash.org/viewBuildError.php?type=1buildid=2336790) This can be fixed by making get_stl_prime_list() a static function, as in the attached patch. == Issue History Date ModifiedUsername FieldChange == 2012-06-05 16:13 Daniel R. GomezNew Issue 2012-06-05 16:13 Daniel R. GomezFile Added: cmake-hashtable-fix.patch == -- 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] libarchive and SCHILY.fflags
On 06/05/2012 04:04 PM, Kornel Benko wrote: However, there were very few changes between the two versions of libarchive, at least upstream: $ git rev-list --count 28267d8..v3.0.3 Maybe this version (3.0.2) is erroneous too. The last working version on ubuntu 11.10 was libarchive1_2.8.4-1ubuntu0.11.10.1_amd64.deb ...but wasn't it reported that building with the builtin cmlibarchive works? That is 3.0.2 plus a few changes (upstream commit 28267d8). -Brad -- 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] libarchive and SCHILY.fflags
On 06/05/2012 03:55 PM, Kornel Benko wrote: Ok, I created a dir with 340 entries. (330 entries was not enough). Thanks. I see the header in the tarball you sent: $ tar xvzf ../data.tgz |wc -l tar: Ignoring unknown extended header keyword `SCHILY.fflags' 341 However, I cannot reproduce it. I built libarchive 3.0.3 from upstream and built CMake 2.8.8 against it: $ tar --version tar (GNU tar) 1.26 $ .../bin/cmake --version cmake version 2.8.8 $ ldd .../bin/cmake |grep libarchive libarchive.so.12 = .../lib/libarchive.so.12 (0x7fd4a999a000) $ strings .../lib/libarchive.so.12 |grep 3.0 libarchive 3.0.3 I can create a tarball from the same directory extracted from yours and it has no trouble: $ .../bin/cmake -E tar cf xx.tar xx $ tar xvf xx.tar |wc -l 341 I can make a much bigger one without trouble too: $ for n in $(seq 1 4096); do echo $n xx/$n; done $ .../bin/cmake -E tar cf xx.tar xx $ tar xvf xx.tar |wc -l 4097 Is there any change in Ubuntu's package for libarchive that is not upstream? This may also depend on the filesystem. Are you using selinux? -Brad -- 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] conditionals in generator expressions
Brad King wrote:
On 05/25/2012 05:18 PM, Stephen Kelly wrote:
By the way, another thing we would need to cover with this is linking to
another library based on the value of a property.
https://codereview.qt-project.org/#change,26577
That one doesn't have to be delayed until generation time, but if we
did have generate-time conditionals they could be used for this.
I was thinking about cases like this:
add_executable(Foo ${Foo_SRCS})
# ... Later
get_target_property(is_win_exe Foo WIN32_EXECUTABLE)
if (is_win_exe)
# ...
endif()
# ... Later
set_target_properties(Foo PROPERTIES WIN32_EXECUTABLE True)
I'd like to know the final content of the property, so that I can link the
static lib in if required.
We're in agreement that this is turning into a declarative spec.
I thought about this some more and I think I don't understand what you mean
by this. Do you mean that the contents of the generator expressions should
be declarative expressions?
If we keep the evaluation of it at generate time then there is no
chance that imperative logic will conflict because the imperative
part runs only during the configuration step.
I thought maybe we can discard the idea of using generator expressions
built into the property content, and introduce a new finalize() command
similar to macro() and function():
It would have to run once for each configuration to be generated
and receive said configuration as an argument. The implementation
would have to fork the entire representation into independent
per-configuration branches (cmMakefile, cmTarget, etc.). It would
also allow imperative logic after the end of configuration or during
generation time which should be avoided for the reason above.
So far we don't have agreement about how this should look language-wise as
far as I can tell. I agree with David that stuffing it into the strings
harms readability.
Depending on what you meant regarding declarative specification here
(http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/3615/focus=3768),
it might be that we haven't found the right idea yet, and we need some more
ideas.
I had another idea inspired by javascript, which allows calling any function
with a different 'this' object (ie, a functional spec rather than
declarative):
generator_expression(myGenExpr)
# The target this expression is called on is available with the
# alias 'this_Target'. The configuration is available with the
# alias 'this_Config' (or this_BUILD_TYPE, or ...).
# Maybe 'this_VARIABLE_SCOPE' could be used to determine whether we're
# populating a variable for PUBLIC consumption (from imported
# targets later), or just for use while building this target.
if (this_Config STREQUAL COVERAGE)
generate_resolved(/foo/bar) # This command is like
# 'return'. No further commands in this generator_expression
# are executed
endif()
if (this_Config STREQUAL RELEASE)
get_target_property(propValue this_Target SOME_SPECIAL_PROP)
# We can't set properties on the target in a generator_expression.
if (propValue)
generate_resolved(/migs/mags)
endif()
endif()
if (this_Config STREQUAL DEBUG)
set(resolvedStuff)
if (BUILD_TESTING)
list(APPEND resolvedStuff /blip/)
endif()
if (LANGUAGE STREQUALS CXX)
list(APPEND resolvedStuff /boog/)
endif()
generate_resolved(resolvedStuff)
endif()
# Implicit generate_resolved()
end_generator_expression()
add_library(Foo ${Foo_SRCS})
set_property(TARGET Foo APPEND
PROPERTY /bing/trog;$GENERATOR:myGenExpr;/ming/mong
)
The $GENERATOR:someName could similarly be used for defines and other
places where we are discussing adding this feature.
I don't know if there's any reason the language can't or shouldn't be used
in this way (it may lead to some odd rules about when
${Qt5WinMain_LIBRARIES} is resolved for example), but it seems we still need
ideas on how to make this whole target orientation concept work.
Thanks,
Steve.
--
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] libarchive and SCHILY.fflags
On 06/05/2012 04:43 PM, Brad King wrote:
Is there any change in Ubuntu's package for libarchive that is
not upstream?
I traced through the source to see how SCHILY.fflags can ever
be added to the archive. I think it depends on whether the
HAVE_STRUCT_STAT_ST_FLAGS test is true when libarchive is built:
https://github.com/libarchive/libarchive/blob/v3.0.3/libarchive/archive_read_disk_entry_from_file.c#L174
Try the patch below when building CMake against Ubuntu's libarchive.
-Brad
$ git diff |cat
diff --git a/Source/cmArchiveWrite.cxx b/Source/cmArchiveWrite.cxx
index dc6b749..b410e44 100644
--- a/Source/cmArchiveWrite.cxx
+++ b/Source/cmArchiveWrite.cxx
@@ -240,6 +240,7 @@ bool cmArchiveWrite::AddFile(const char* file,
// Clear acl and xattr fields not useful for distribution.
archive_entry_acl_clear(e);
archive_entry_xattr_clear(e);
+ archive_entry_set_fflags(e, 0, 0);
if(archive_write_header(this-Archive, e) != ARCHIVE_OK)
{
this-Error = archive_write_header: ;
--
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] libarchive and SCHILY.fflags
Am Dienstag, 5. Juni 2012 um 16:43:15, schrieb Brad King brad.k...@kitware.com On 06/05/2012 03:55 PM, Kornel Benko wrote: Ok, I created a dir with 340 entries. (330 entries was not enough). Thanks. I see the header in the tarball you sent: $ tar xvzf ../data.tgz |wc -l tar: Ignoring unknown extended header keyword `SCHILY.fflags' 341 However, I cannot reproduce it. I built libarchive 3.0.3 from upstream and built CMake 2.8.8 against it: $ tar --version tar (GNU tar) 1.26 $ .../bin/cmake --version cmake version 2.8.8 $ ldd .../bin/cmake |grep libarchive libarchive.so.12 = .../lib/libarchive.so.12 (0x7fd4a999a000) $ strings .../lib/libarchive.so.12 |grep 3.0 libarchive 3.0.3 Same tar version here. I can create a tarball from the same directory extracted from yours and it has no trouble: Not nice, isn't it? $ .../bin/cmake -E tar cf xx.tar xx $ tar xvf xx.tar |wc -l 341 I can make a much bigger one without trouble too: $ for n in $(seq 1 4096); do echo $n xx/$n; done $ .../bin/cmake -E tar cf xx.tar xx $ tar xvf xx.tar |wc -l 4097 I can do this too, but only if explicitly called # cmake -E tar cf xx.tar xx/* == ok but # cmake -E tar cf xx.tar xx == error in xx.tar Is there any change in Ubuntu's package for libarchive that is not upstream? I don't know, but it would surprise me ... Maybe it is one of the underlying libs, like libattr.so.1 or libnettle.so.4 . This guessing makes me not happy. #ldd /usr/lib/x86_64-linux-gnu/libarchive.so.12.0.3 linux-vdso.so.1 = (0x7fff197ff000) libacl.so.1 = /lib/x86_64-linux-gnu/libacl.so.1 (0x7f693958a000) libattr.so.1 = /lib/x86_64-linux-gnu/libattr.so.1 (0x7f6939385000) liblzma.so.5 = /usr/lib/x86_64-linux-gnu/liblzma.so.5 (0x7f6939162000) libbz2.so.1.0 = /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x7f6938f52000) libz.so.1 = /lib/x86_64-linux-gnu/libz.so.1 (0x7f6938d3b000) libxml2.so.2 = /usr/lib/x86_64-linux-gnu/libxml2.so.2 (0x7f69389df000) libnettle.so.4 = /usr/lib/x86_64-linux-gnu/libnettle.so.4 (0x7f69387b9000) libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7f69383fc000) libpthread.so.0 = /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f69381de000) libdl.so.2 = /lib/x86_64-linux-gnu/libdl.so.2 (0x7f6937fda000) libm.so.6 = /lib/x86_64-linux-gnu/libm.so.6 (0x7f6937ce) /lib64/ld-linux-x86-64.so.2 (0x7f6939a5b000) This may also depend on the filesystem. EXT3 Are you using selinux? The selinux libraries are installed, but selinux and selinux-basics are not, so the answer should be no. -Brad Kornel signature.asc Description: This is a digitally signed message part. -- 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] Welcome to June, time for the next release candidate
I would like to have the Ninja generator enabled on all Platforms. It is importand for cross Development, not only as native Build Tool! With regards Claus On 04.06.2012, at 23:13, David Cole david.c...@kitware.com wrote: We are preparing to build CMake 2.8.9, release candidate one, in the next few days (or possibly as late as next week). Is there any pending/outstanding work that anybody thinks is critical for inclusion in CMake 2.8.9? (I don't want to trigger a flurry of activity by sending this out... but I suppose it's better to have it before we decide to cut rc1 than after. ;-) Thanks, David -- 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 -- 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] libarchive and SCHILY.fflags
Am Dienstag, 5. Juni 2012 um 16:27:28, schrieb Brad King brad.k...@kitware.com On 06/05/2012 04:04 PM, Kornel Benko wrote: However, there were very few changes between the two versions of libarchive, at least upstream: $ git rev-list --count 28267d8..v3.0.3 Maybe this version (3.0.2) is erroneous too. The last working version on ubuntu 11.10 was libarchive1_2.8.4-1ubuntu0.11.10.1_amd64.deb ...but wasn't it reported that building with the builtin cmlibarchive works? That is 3.0.2 plus a few changes (upstream commit 28267d8). Sorry, I was not aware of the version of the builtin cmlibarchive. I reported it. And yes, this was working. -Brad Kornel signature.asc Description: This is a digitally signed message part. -- 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] libarchive and SCHILY.fflags
Am Dienstag, 5. Juni 2012 um 17:11:47, schrieb Brad King brad.k...@kitware.com
On 06/05/2012 04:43 PM, Brad King wrote:
Is there any change in Ubuntu's package for libarchive that is
not upstream?
I traced through the source to see how SCHILY.fflags can ever
be added to the archive. I think it depends on whether the
HAVE_STRUCT_STAT_ST_FLAGS test is true when libarchive is built:
https://github.com/libarchive/libarchive/blob/v3.0.3/libarchive/archive_read_disk_entry_from_file.c#L174
Try the patch below when building CMake against Ubuntu's libarchive.
-Brad
$ git diff |cat
diff --git a/Source/cmArchiveWrite.cxx b/Source/cmArchiveWrite.cxx
index dc6b749..b410e44 100644
--- a/Source/cmArchiveWrite.cxx
+++ b/Source/cmArchiveWrite.cxx
@@ -240,6 +240,7 @@ bool cmArchiveWrite::AddFile(const char* file,
// Clear acl and xattr fields not useful for distribution.
archive_entry_acl_clear(e);
archive_entry_xattr_clear(e);
+ archive_entry_set_fflags(e, 0, 0);
if(archive_write_header(this-Archive, e) != ARCHIVE_OK)
{
this-Error = archive_write_header: ;
This one works. But wait ... checking again without the patch ... ERROR
You made it.
Kornel
signature.asc
Description: This is a digitally signed message part.
--
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] [CMake] Nina Generator on Windows generates too long link cmd lines
On 04.06.2012 23:13, Bill Hoffman wrote: On 6/4/2012 2:22 PM, Peter Kümmel wrote: We use ninja's response files: # Rule for linking CXX static library. rule CXX_STATIC_LIBRARY_LINKER command = E:\sandbox\MinGW32\bin\ar.exe cr $out $LINK_FLAGS @$out.rsp description = Linking CXX static library $out rspfile = $out.rsp rspfile_content = $in But the problem is, that ar under windows doesn't like paths with one single '\' and on some UNIXs doesn't support response files at all. OK, my mistake. The tool has to support response files. So, currently with nmake files we do something like this: Platform/Windows.cmake: # for nmake make long command lines are redirected to a file # with the following syntax, see Windows-bcc32.cmake for use IF(CMAKE_GENERATOR MATCHES NMake) SET(CMAKE_START_TEMP_FILE @\n) SET(CMAKE_END_TEMP_FILE \n) ENDIF(CMAKE_GENERATOR MATCHES NMake) Does MinGW32 ar use a different format response file than MS link.exe? Seems like this should go in the Platform file. Maybe we don't use it on UNIX? -Bill -- I found the problem: using CMAKE_C_USE_RESPONSE_FILE_FOR_OBJECTS was wrong. I've fixed the patch: 1. also write rules with response files enabled 2. then the command line length is checked by cmake and if it is too long the rule with the response file is used 3. when MinGW is used the slashed pathes are used because ar.exe can't read \ in response files. The commits are here http://cmake.org/gitweb?p=stage/cmake.git;a=shortlog;h=refs/heads/ninja-rspfile and I've merged it into next. Peter -- 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
