Re: [cmake-developers] Welcome to June, time for the next release candidate
Am Montag, 4. Juni 2012 um 17:13:26, schrieb David Cole > 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 : > Am Montag, 4. Juni 2012 um 17:13:26, schrieb David Cole > > >> 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 : > 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 : > 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] ninja failing CompileCommandOutput
On Mon, Jun 4, 2012 at 4:41 PM, Brad King wrote: > On 06/04/2012 10:25 AM, Bill Hoffman wrote: > > On 6/1/2012 1:55 PM, Brad King wrote: > >> The generator is supposed to produce a file that lists all the > >> compiler invocation command lines in a JSON format. The test > >> runs a build with the option and then runs a program that reads > >> the generated file and re-plays the commands. The test and its > >> C++ program should not need modification because it works for the > >> Makefile generator. The Ninja generator will need to generate > >> the properly encoded commands like the Makefile generator does. > > > > Seems like the json file is reasonable: > > > >"command": "C:\\PROGRA~2\\MICROS~1.0\\VC\\bin\\cl.exe /nologo > > /DWIN32 /D_WINDOWS /W3 /Zm1000 /EHsc /GR /D_DEBUG /MDd /Zi /Ob0 /Od > > /RTC1 -I\"c:\\Users\\hoffman\\Work\\My > > Builds\\NinjaCMake\\Tests\\CompileCommandOutput\\..\\..\\Source\" > > /TP > > /FoCMakeFiles/CompileCommandOutput.dir/compile_command_output.cxx.obj > > /FdTARGET_PDB -c \"c:\\Users\\hoffman\\Work\\My > > > Builds\\NinjaCMake\\Tests\\CompileCommandOutput\\compile_command_output.cxx\"", > >"file": "c:\\Users\\hoffman\\Work\\My > > > Builds\\NinjaCMake\\Tests\\CompileCommandOutput\\compile_command_output.cxx" > > }, > > > > the test driver should be able to read a file with \\ in it, > > and the generator output is fine. > > The topic was first brought up here: > > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/3678 > > Context of this discussion: > > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/3774 > > Origin of parser in question: > > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0e6b05fc > > Manuel, as author of this parser can you comment please? >From taking a very high level look it seems to me like the parser probably needs fixing on Windows - I unfortunately don't have a Windows machine around (I really need to get one ...), but I think disabling it for Windows is fine for now - as Stephen points out in a later email clang tooling for Windows is not that useful yet due to clang restrictions. If somebody expresses a strong need for the Windows fixes, I can prioritize them; please let me know in that case. Cheers, /Manuel -- 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 > > 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 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
2012/6/5 Kornel Benko : > Am Dienstag, 5. Juni 2012 um 10:11:40, schrieb Eric Noulard > > >> 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? Nope. 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. I'm not saying that should be you or the Ubuntu packager but I have no time (now) to do that and since the packager knows his package better than me I would kindly ask for his help. > 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. The libarchive from Ubuntu may well be patched and/or compiled with conflicting options which makes it incompatible with the CMake usage. 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. Since it works with cmlibarchive my question was simple, could the ubuntu package check why it's breaking in Ubuntu. > We already reacted once (changing archive_write_set_format_ustar() to > archive_write_set_format_pax_restricted()). Yes but this action was widening the compatibility. pax_restricted --> gnutar may be narrowing it. > Never mind, I did not want to be importunate ... You don't. Personnally I like discussion, so no problem. I do not pretend I'm right in this case either, but I'm clearly lacking time to investigate the issue and I'm glad you already seek & tests for understanding the issue. However from my point of view is that we now know the symptom, but we do not know the reason. Why is it working with cmlibarchive and not with system libarchive. I'm using Debian wheezy 64 bits, and I do not have any problem when using system libarchive: ldd /home/erk/CMake/cmake-Verk-HEAD/bin/cmake linux-vdso.so.1 => (0x7fff387ff000) libarchive.so.12 => /usr/lib/x86_64-linux-gnu/libarchive.so.12 (0x7f7424a8d000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f7424889000) ... ldd /home/erk/CMake/cmake-Verk-HEAD/bin/cpack linux-vdso.so.1 => (0x7fff79dff000) libarchive.so.12 => /usr/lib/x86_64-linux-gnu/libarchive.so.12 (0x7fb676d4f000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7fb676b4b000) ... So my question is, why is it happening on Ubuntu 12.04, and may be why is it NOT happening on 11.10 or 11.04 ?? -- 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
On Tue, Jun 5, 2012 at 8:17 AM, Eric Noulard wrote: > 2012/6/5 Kornel Benko : > 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. > 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 but many archive portability concerns were lifted by updating to a libarchive that included this: https://github.com/libarchive/libarchive/commit/de60ddd0 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 -- 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 > On Tue, Jun 5, 2012 at 8:17 AM, Eric Noulard wrote: > > 2012/6/5 Kornel Benko : > > 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
Stephen Kelly wrote: > Stephen Kelly wrote: > >> Brad King wrote: >>> The current implementation can be refactored in a way that >>> should make Xcode easy. >> >>> Then simply use the patch below for Xcode. >> >> Great, thanks, all done. >> >> I'll merge it into next next week when I can look at the dashboard. >> > > I've merged it now. There's a surprising failure which I'm not able to debug: http://open.cdash.org/testDetails.php?test=148807497&build=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? 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 11:40 AM, Stephen Kelly wrote: > http://open.cdash.org/testDetails.php?test=148807497&build=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
Re: [cmake-developers] Adding logic to CMake for -fPIE and -fPIC
Brad King wrote: > On 06/05/2012 11:40 AM, Stephen Kelly wrote: >> http://open.cdash.org/testDetails.php?test=148807497&build=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. > 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... 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
[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] Adding logic to CMake for -fPIE and -fPIC
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. 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. -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 (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] Welcome to June, time for the next release candidate
Am Montag, 4. Juni 2012, 17:13:26 schrieb David Cole: > 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. ;-) I always had the bugreport #13216 marked as unread here because I wanted to fix it. This is now finally done and the fix is merged to next. Nothing really serious, just FindPythonLibs not honoring EXACT. Eike 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
Hi Bill, IMO response file handling should NOT disabled for unix host at all. With this patch, it may be checked on Darwin and perhaps the same is needed for BSD? claus-kleins-macbook-pro:AgentProBuild clausklein$ make CMakeCache.txt -- The C compiler identification is GNU 4.7.0 -- The CXX compiler identification is GNU 4.7.0 -- Could not determine Eclipse version, assuming at least 3.6 (Helios). Adjust CMAKE_ECLIPSE_VERSION if this is wrong. -- Checking whether /opt/local/bin/ar tool supports response @file option -- Checking whether /opt/local/bin/ar tool supports response @file option - no -- Checking whether C compiler has -isysroot -- Checking whether C compiler has -isysroot - yes -- Checking whether C compiler supports OSX deployment target flag -- Checking whether C compiler supports OSX deployment target flag - yes -- Check for working C compiler using: Ninja -- Check for working C compiler using: Ninja -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Checking whether /opt/local/bin/ar tool supports response @file option -- Checking whether /opt/local/bin/ar tool supports response @file option - no -- Checking whether CXX compiler has -isysroot -- Checking whether CXX compiler has -isysroot - yes -- Checking whether CXX compiler supports OSX deployment target flag -- Checking whether CXX compiler supports OSX deployment target flag - yes -- Check for working CXX compiler using: Ninja -- Check for working CXX compiler using: Ninja -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done ... Claus PlatformDarwin-GNU.patch Description: Binary data On 04.06.2012, at 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 -- 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
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 -- 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 > 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
[cmake-developers] [CMake 0013272]: Use of [o]stringstream instead of strstream breaks the build on older systems
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13272 == Reported By:Daniel R. Gomez Assigned To: == Project:CMake Issue ID: 13272 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2012-06-05 16:03 EDT Last Modified: 2012-06-05 16:03 EDT == Summary:Use of [o]stringstream instead of strstream breaks the build on older systems Description: Most CMake code uses strstream when stringstream is not available. However, the following files in the git nightly branch currently do not: Source/cmQtAutomoc.cxx Source/cmGlobalNinjaGenerator.cxx Source/cmLocalNinjaGenerator.cxx Source/cmNinjaTargetGenerator.cxx Source/cmNinjaNormalTargetGenerator.cxx The build failures may be reviewed at http://open.cdash.org/viewBuildError.php?buildid=2336790 == Issue History Date ModifiedUsername FieldChange == 2012-06-05 16:03 Daniel R. GomezNew 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] libarchive and SCHILY.fflags
Am Dienstag, 5. Juni 2012 um 15:35:15, schrieb Brad King > 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=1&buildid=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;$;/ming/mong" ) The $ 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 > 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 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 > 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] Welcome to June, time for the next release candidate
I would like that, too. But I am going to be firm in saying that I will not allow that change until the "Nightly Expected" dashboard section is completely green with respect to all ninja submissions. So I don't anticipate that happening in time for 2.8.9. I'd be happy to be proven wrong, though. :-) David On Tue, Jun 5, 2012 at 5:22 PM, Claus Klein wrote: > 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 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 > -- 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 > 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