Re: [cmake-developers] Xcode 7 tbd library stub support
On 08/24/2015 04:43 PM, Gregor Jasny via cmake-developers wrote: I just pushed a topic branch to add support for Xcode 7 TDB files: http://www.cmake.org/gitweb?p=stage/cmake.git;a=shortlog;h=refs/heads/apple-tbd-stubs Thanks. Please merge to 'next' when ready. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [PATCH] Add support for Xcode ORGANIZATIONNAME project setting via CMAKE_XCODE_ORGANIZATIONNAME.
Hi all, Using the Xcode project generator, there didn't seem to be a way to specify a project-level organization name, so I added the ability to do just that by setting CMAKE_XCODE_ORGANIZATIONNAME. For example, if CMAKE_XCODE_ORGANIZATIONNAME is set to My Company, Inc., when you create new files within Xcode, you'll now end up with a header comment similar to the following: // // Foo.cpp // some-project // // Created by Joe Schmoe on 8/25/15. // Copyright (c) 2015 My Company, Inc. All rights reserved. // Without CMAKE_XCODE_ORGANIZATIONNAME set (and without this patch), header comments look like this: // // Foo.cpp // some-project // // Created by Joe Schmoe on 8/25/15. // // I tried to adhere to the surrounding coding style and whatnot. Let me know if anything needs massaging. Cheers, Cody 0001-Add-support-for-Xcode-ORGANIZATIONNAME-project-setti.patch Description: Binary data -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CPack] CPackDeb and fakeroot
Le 25/08/15 16:48, Eric Noulard a écrit : Hi guys, Some of my thoughts about this one. Hi, thanks you for your quick reply! 2015-08-25 15:42 GMT+02:00 Raffi Enficiaud [snip] Yes but the may be interesting part should be in: /«BUILDDIR»/build_dir/_CPack_Packages/Linux/DEB/Deb.log which is not displayed in the previous file. Sorry for that, I forgot to tell that everything works ok without pbuilder. So I believe this is the issue, I will check next time I build this. Basically in my case, the debian/rule file calls cmake and cpack to generate the deb packages. pbuilder mimics a clean build environment that is used on Launchpad for isolating the build, and I believe (not sure) it calls fakeroot under the hood. pbuilder calls fakeroot for sure: In your log one can see: make[1]: Leaving directory `/«BUILDDIR»/build_dir' fakeroot debian/rules binary-arch touch debian/files cpack --version cpack version 3.3.20150824 [snip] The introduction of fakeroot usage for CPackDeb was made for that issue: http://public.kitware.com/Bug/view.php?id=10325 with the small follow-up you cited: http://public.kitware.com/Bug/view.php?id=13118 Right, but again the main idea seems to be able to set the uid/guid properly in the tar. fakeroot is not used unless it is detected as installed on the system. The question in your case is, why is fakeroot installed AND not working when used in pbuilder. My guess is that pbuilder is ALREADY calling fakeroot and that fakeroot cannot be called from within fakerootED environnement (nested fakeroot is unsupported). I also think this is the issue, nesting fakeroot is not supported. I would suggest checking (in CPackDeb generator code) whether if CPack has been called in a fakerootED environment. This can be done by checking whether if FAKEROOTKEY env var is defined or not. If fakeroot is already in action then one should not call fakeroot again (whatever the fakerootED user is). I did not know about this key, that would be a nice/clean resolution to the problem. The #13700 bugs referred hereafter confirms this kind of issue: http://public.kitware.com/Bug/view.php?id=13700 - unifying the tool used for creating the tar: from the code in cmCPackDebGenerator.cxx, some compression schemes use the native tar while some others use the cmake tar. This is explained in Source/CPack/cmCPackDebGenerator.cxx // NOTE: // A debian package .deb is simply an 'ar' archive. The only subtle difference // is that debian uses the BSD ar style archive whereas most Linux distro have // a GNU ar. // See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=161593 for more info // Therefore we provide our own implementation of a BSD-ar: static int ar_append(const char*archive,const std::vectorstd::string files); I don't really known whether if this argument still apply nowadays and I let you read the discussion on bugs.debian.org http://bugs.debian.org. Ok. Let's not burn our fingers on this direction then :) What would be the best option for you? I let Domen answer for that, I was just jumping in to let you all know the bits of the story I remember. I believe it would address this issues already in the backlog (and help ppl deploy things on Launchpad with cmake): - http://public.kitware.com/Bug/view.php?id=13700 - http://public.kitware.com/Bug/view.php?id=11766 Like I said 13700 should be easy to fix by avoiding nested fakeroot call. 11766 is another story. I think that adding ownership option to cmake -E tar may be useful but not that urgent considering that most of these issues can be fixed in another easy mean. If I understand the issue well, their concern https://htcondor-wiki.cs.wisc.edu/index.cgi/tktview?tn=1863 was about doing some experiments for having root/root uid/guid + some fancy block size. root/root is ok now with fakeroot, and they abandoned the block_size fancy options. The thing is that root/root implementation today is not fully ok due to the bug exposed on this thread (nested fakeroot). That said libarchive now seems to support BSD tar https://github.com/libarchive/libarchive/tree/master/tar and ownership using set_ownership(struct archive_write_disk *) API. so may be it's possible to get rid of the BSD tar implementation embedded in cmCPackDebGenerator.cxx and add appropriate calls to libarchive. That would be a solution, but it is hard for me to see the gain of touching that many files instead of having the nice FAKEROOTKEY detection. Thanks again! Raffi -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses:
Re: [cmake-developers] ExternalProject: Use native paths as substitute for directory tokens
Dear CMake developers, any thoughts on the fix? :) Best regards, Stefan Kislinskiy Von: cmake-developers [cmake-developers-boun...@cmake.org] im Auftrag von Kislinskiy, Stefan [s.kislins...@dkfz-heidelberg.de] Gesendet: Freitag, 21. August 2015 23:56 An: David Cole; James Johnston Cc: cmake-developers@cmake.org Betreff: Re: [cmake-developers] ExternalProject: Use native paths as substitute for directory tokens What do you think about the new patch I attached to this mail? It adds an option NATIVE_DIR_TOKENS to ExternalProjects_Add. I also attached a CMake script file which tests/shows this feature. Stefan Kislinskiy Von: cmake-developers [cmake-developers-boun...@cmake.org] im Auftrag von David Cole via cmake-developers [cmake-developers@cmake.org] Gesendet: Donnerstag, 20. August 2015 23:20 An: James Johnston Cc: cmake-developers@cmake.org Betreff: Re: [cmake-developers] ExternalProject: Use native paths as substitute for directory tokens It's exactly what I am concerned about: You're asking to change the behavior of something for EVERYONE to solve a problem which you have encountered. If you change it the way you have proposed, you will cause problems for others. It has worked the way it is now since ExternalProject_Add was introduced in CMake 2.8. Changing it unconditionally the way you propose is simply not feasible for backwards compatibility. I think commands that take native paths ought NOT to use the *_DIR replacement values, and instead, ought to pass in variables that contain the native paths in the first place. David C. On Thu, Aug 20, 2015 at 2:58 PM, James Johnston johnstonj.pub...@codenest.com wrote: Hi, Funny you are mailing the list about this, since I just ran into this same issue today building something totally different from Boost... In this case it's a build tool that thinks the /U in C:/Users is a new command line argument, that isn't recognized - and then the subsequent s also ends up unrecognized... and it all fails... And it has nothing to do with the working directory, so _Add_Step(WORKING_DIRECTORY) isn't a possible workaround for me. I think the issue with globally making this change to the existing tokens is that there could be some external tool/program that is EXPECTING to get CMake paths, not native paths. Who knows? I am guessing that is what David Cole was concerned about. Maybe the right answer is to introduce some NEW tokens while leaving the behavior of the old ones unchanged. E.g. BINARY_DIR_NATIVE etc. It would be good if the patch updates the documentation of ExternalProject and clearly states the path format of BINARY_DIR vs BINARY_DIR_NATIVE. Then the user can pick whichever one suits them best, depending on the tool being invoked. Furthermore, sometimes BINARY_DIR_NATIVE still needs to be replaced with a CMake path, not native path. For example, if the token is being found in a property like WORKING_DIRECTORY that eventually gets passed to add_custom_command(WORKING_DIRECTORY) then I'm guessing still has to be a CMake path. I am guessing this is what David Cole was also concerned about. I still think your original method of building Boost is a bit unusual and would be better served by _Add_Step with a custom working directory - because that's the publicly documented/standard way of changing the working directory, but that is up to you. :) Best regards, James Johnston On Thu, 20 Aug 2015 14:37:08 + Stefan Kislinskiy s.kislins...@dkfz-heidelberg.de wrote Hi, thank you for our suggestions. I am aware that I can solve my example differently and that it might look not directly connected the proposal, but well, it is an example just to show a single case and why it matters. :) I did not want to discuss the example itself. Working around here would just resolve a symptom. My point is the overall problem that would persist: A big part of ExternalProject is to issue commands for predefined and custom steps. Those commands are supposed to be executed by the shell/command line. According to the documentation and the source code of ExternalProject, directory tokens are mainly supposed to be replaced in commands. It is my understanding, that it is a bug, if CMake isn't able to assemble these commands correctly. This would include usage of the correct path style of the OS for shell/command line commands. As directory tokens are replaced internally right before a shell/command line command is assembled, I can't see why this would be kind of API-breaking. You cannot interfere in your CMake code with these internal replacements. Therefore I would still prefer my solution as it is pretty simple without adding even more features to ExternalProject and in my opinion without breaking code in the wild. It is a true bug fix instead of a feature
Re: [cmake-developers] cmake's built-in support for android using nvidia nsight tegra
I worked around that error by editing SDL_android_main.c:
extern C
{
/* Called before SDL_main() to initialize JNI bindings in SDL library */
extern void SDL_Android_Init(JNIEnv* env, jclass cls);
}
So I'm at least able to build again now... Though it still crashes when I
try to run the APK...
On Tue, Aug 25, 2015 at 12:57 AM, Peter List pem.l...@gmail.com wrote:
I'm now attempting to build a simple SDL2 Android application with CMake's
built-in Android support (uses nvidia tegra nsight for visual studio 2010)
SDL2-2.0.3 does not appear to have a NativeActivity example so I'm
attempting to use its android-project folder that includes
SDL2-2.0.3\android-project\src\org\libsdl\app\SDLActivity.java instead.
I'm able to compile my libpemDemos.so project with SDL2 code this way for
armabi-v7a
I also compiled libSDL2.so for armabi-v7a using ndk-build (not nvidia
tegra nsight), and I'm able to reference it from my pemDemos.vcxproj
I verified my pemDemos.vcxproj linker step does includes this:
-L[path]/SDL2-2.0.3/libs/armeabi-v7a -lSDL2
However, I'm getting a linker error when I try to add SDL_android_main.c
to my build:
1 pemDemos.dir/Debug/SDL_android_main.o: In function
`Java_org_libsdl_app_SDLActivity_nativeInit(_JNIEnv*, _jclass*, _jobject*)':
1 [path]\SDL2-2.0.3\src\main\android\SDL_android_main.c(23): undefined
reference to `SDL_Android_Init(_JNIEnv*, _jclass*)'
1collect2.exe : error : ld returned 1 exit status
If I comment out the following one line then I can build my libpemDemos.so
again:
SDL_Android_Init(env, cls);
However that of course fails when I try to run it.
I don't understand why the linker doesn't see `SDL_Android_Init(_JNIEnv*,
_jclass*)'. I have -lSDL2 (and I know the linker is finding libSDL.so
because it gives an error if I change vcxproj settings to do -lSDLzzz
instead of -lSDL). Plus I even verified that libSDL2.so has
SDL_Android_Init():
readelf -Ws [path]\SDL2-2.0.3\libs\armeabi-v7a\libSDL2.so | grep
SDL_Android_Init
216: 0002f60d 332 FUNCGLOBAL DEFAULT8 SDL_Android_Init
So why doesn't my linker step find SDL_Android_Init()?
thank you for any leads
On Mon, Aug 24, 2015 at 8:20 PM, Peter List pem.l...@gmail.com wrote:
Per Brad's suggestion, I removed this line from my CMakeLists.txt:
add_library(${PROJECT_NAME} SHARED ${SRC_LIST})
And I added these lines:
set(CMAKE_ANDROID_GUI TRUE)
set(CMAKE_ANDROID_API 19) # Kindle Fire HD 6
set(CMAKE_ANDROID_API_MIN 19) # Kindle Fire HD 6
add_executable(${PROJECT_NAME} ${SRC_LIST})
I am now able to generate a Visual Studio 2010 pemDemos.sln that includes
a pemDemos.vcxproj with a configuration properties section Ant Built.
From inside Visual Studio, I'm able to build an APK and then ctrl+F5 to run
it on my device.
Unfortunately, cmake did not generate AndroidManifest.xml, so I had to
supply my own using the aforementioned execute_process() with android.bat.
At this point my app just displays a Hello World, PemActivity message
that it gets from build-android\android\res\layout\main.xml. So it's not
using android_native_app_glue.c,h to point to my main.cpp code in
libpemDemos.so yet. So maybe cmake doesn't do that part automatically
for me? I also don't see a tutorial or simple hello world demo project for
this... However, I can at least use AndroidNativeApp.vcxproj as a
reference.
thank you best regards
On Mon, Aug 24, 2015 at 9:49 AM, Brad King brad.k...@kitware.com wrote:
On 08/23/2015 04:44 PM, Peter List wrote:
How do I tell cmake to include Ant Build in my vcxproj, so that
it will package my project into an APK? I can generate vcxproj
that builds a Tegra-Android *.so file, but it does not build me
an APK, and my vcxproj is missing the Ant Build property section.
You need to set the ANDROID_GUI target property on an exe:
http://www.cmake.org/cmake/help/v3.3/prop_tgt/ANDROID_GUI.html
Additional settings have been added in post-3.3 development:
VS: Add more Nsight Tegra generator Android property settings
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8c0afaf4
-Brad
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] SDL2 + CMake + Android (on Windows)
What's the best way to build a hello world SDL2 project with CMake for Android (on Windows)? -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CPack] CPackDeb and fakeroot
Le 25/08/15 16:48, Eric Noulard a écrit : I would suggest checking (in CPackDeb generator code) whether if CPack has been called in a fakerootED environment. This can be done by checking whether if FAKEROOTKEY env var is defined or not. If fakeroot is already in action then one should not call fakeroot again (whatever the fakerootED user is). Hmmm, unfortunately it does not work. This variable does not exist on the fakerooted shell. I think there is no good way to detect that we are in a fakerooted environment because their purpose is to mimic the commands as if the real root user is entering them (and introspection should not be possible by design). I see two technical solutions: - either using the system tar: this would not work in the case of cross compilation (and in some circumstances only) but would work in the other case. I believe that all the debian packaging tools are just using the system provided tar, so this should closely mimic the debian-packaging machinery better, - or using a CPACK variable to avoid having fakeroot executed I see several workarounds/hacks: - executing with fakeroot in cpack first and in case of failure falling back to run tar without fakeroot - detect if the current user is root already Raffi -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Adding Swift support to CMake
Hi Eric Brad, On 15/07/15 12:16, Eric Wing wrote: On 7/7/15, Brad King brad.k...@kitware.com wrote: On 07/02/2015 07:54 PM, Eric Wing wrote: Thank you Brad. When you are ready, let me know how I can help next. I have basic support with the Xcode generator done. Please try out this commit: Add rudimentary support for the Apple Swift language with Xcode http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bf112531 I was just digging through OSX 10.11 / Xcode 7 errors and noticed that the Swift tests fail with Xcode7: https://open.cdash.org/buildSummary.php?buildid=3972344 CompileSwift normal x86_64 /Users/builder/external/CMake/Tests/SwiftOnly/main.swift cd /Users/builder/external/CMake/Tests/SwiftOnly /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swift -frontend -c -primary-file /Users/builder/external/CMake/Tests/SwiftOnly/main.swift -target x86_64-apple-macosx10.11 -enable-objc-interop -sdk /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk -I /Users/builder/external/CMake-xcode-dbg-x86_64/Tests/SwiftOnly/Debug -F /Users/builder/external/CMake-xcode-dbg-x86_64/Tests/SwiftOnly/Debug -serialize-debugging-options -Xcc -I/Users/builder/external/CMake-xcode-dbg-x86_64/Tests/SwiftOnly/SwiftOnly.build/Debug/SwiftOnly.build/swift-overrides.hmap -Xcc -I/Users/builder/external/CMake-xcode-dbg-x86_64/Tests/SwiftOnly/Debug/include -Xcc -I/Users/builder/external/CMake-xcode-dbg-x86_64/Tests/SwiftOnly/SwiftOnly.build/Debug/SwiftOnly.build/DerivedSources/x86_64 -Xcc -I/Users/builder/external/CMake-xcode-dbg-x86_64/Tests/SwiftOnly/SwiftOnly.build/Debug/SwiftOnly.build/DerivedSources -Xcc -DCMAKE_INT D IR=\Debug\ -Xcc -working-directory/Users/builder/external/CMake/Tests/SwiftOnly -emit-module-doc-path /Users/builder/external/CMake-xcode-dbg-x86_64/Tests/SwiftOnly/SwiftOnly.build/Debug/SwiftOnly.build/Objects-normal/x86_64/main~partial.swiftdoc -O -module-name SwiftOnly -emit-module-path /Users/builder/external/CMake-xcode-dbg-x86_64/Tests/SwiftOnly/SwiftOnly.build/Debug/SwiftOnly.build/Objects-normal/x86_64/main~partial.swiftmodule -serialize-diagnostics-path /Users/builder/external/CMake-xcode-dbg-x86_64/Tests/SwiftOnly/SwiftOnly.build/Debug/SwiftOnly.build/Objects-normal/x86_64/main.dia -emit-dependencies-path /Users/builder/external/CMake-xcode-dbg-x86_64/Tests/SwiftOnly/SwiftOnly.build/Debug/SwiftOnly.build/Objects-normal/x86_64/main.d -emit-reference-dependencies-path /Users/builder/external/CMake-xcode-dbg-x86_64/Tests/SwiftOnly/SwiftOnly.build/Debug/SwiftOnly.build/Objects-normal/x86_64/main.swiftdeps -o /Users/builder/external/CMake-xcode-dbg-x86_64/Tests/SwiftOnly/Swif t Only.build/Debug/SwiftOnly.build/Objects-normal/x86_64/main.o /Users/builder/external/CMake/Tests/SwiftOnly/main.swift:1:1: error: 'println' has been renamed to 'print' println(SwiftOnly) ^~~ print Swift.println:1:82: note: 'println' has been explicitly marked unavailable here @available(*, unavailable) @inline(never) @_semantics(stdlib_binary_only) func printlnT(value: T) Thanks, Gregor -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] FindZLIB module should find debug and, release variants
Please add each of the _DEBUG and _RELEASE configurations if and only if the corresponding variables are set. Grep for mention of IMPORTED_CONFIGURATIONS in other Modules/Find*.cmake files for examples. I'm assuming that there should be a IMPORTED_LOCATION property defined in all cases as well? The other Find modules aren't entirely consistent for this point, but it would make sense to me to set it to ZLIB_LIBRARY, similar to how FindOpenSSL behaves. Cheers, Michael -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Replace deprecated libarchive functions
Páder Rezső wrote: Hi all, cmake requires libarchive3, but uses old, deprecated libarchive functions. The attached patch solves this. I may be wrong, but I would assume that these are not deprecated libarchive3 functions, but function deprecated _in_ libarchive3, no? Greetings, Eike -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CPack] CPackDeb and fakeroot
Le 26/08/15 00:45, Eric Noulard a écrit : [snip] I see two technical solutions: - either using the system tar: this would not work in the case of cross compilation (and in some circumstances only) but would work in the other case. I believe that all the debian packaging tools are just using the system provided tar, so this should closely mimic the debian-packaging machinery better, Cross-compiling is one thing, cross packaging is another. I think trying to cross-package is a very hard task (unless you simply create a bare archive (tar, zip, etc...) Sorry I wanted to say cross-packaging. Still I think using the system default tar program is a good way to go. - or using a CPACK variable to avoid having fakeroot executed seems awkward to disable black magic with another black magic spell. I agree. I see several workarounds/hacks: - executing with fakeroot in cpack first and in case of failure falling back to run tar without fakeroot - detect if the current user is root already Detecting if user is already root doesn't seems to be such a big hack it should even be robust as well and should be a 2 line modfication in CPackDeb.cmake protecting it even detecting FAKEROOT alltogether. Right, but I am more concerned about the proper way of doing it and not the difficulty. From all this discussion, using fakeroot directly does not look to me as the right solution for having root in the tar, in the first place. So if we are also able to get rid of the fakeroot machinery in cpack, maybe it would be a better solution. Raffi -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CPack] CPackDeb and fakeroot
2015-08-25 23:52 GMT+02:00 Raffi Enficiaud raffi.enfici...@mines-paris.org : Le 25/08/15 16:48, Eric Noulard a écrit : I would suggest checking (in CPackDeb generator code) whether if CPack has been called in a fakerootED environment. This can be done by checking whether if FAKEROOTKEY env var is defined or not. If fakeroot is already in action then one should not call fakeroot again (whatever the fakerootED user is). Hmmm, unfortunately it does not work. This variable does not exist on the fakerooted shell. I think there is no good way to detect that we are in a fakerooted environment because their purpose is to mimic the commands as if the real root user is entering them (and introspection should not be possible by design). You are right the design of fakeroot is to mimic... I tested it using erk@capitaine:tmp$ fakeroot bash root@capitaine:tmp# echo $FAKEROOTKEY 489393277 but it does not seem to be set when fakerooting a simple command (outside a shell). I see two technical solutions: - either using the system tar: this would not work in the case of cross compilation (and in some circumstances only) but would work in the other case. I believe that all the debian packaging tools are just using the system provided tar, so this should closely mimic the debian-packaging machinery better, Cross-compiling is one thing, cross packaging is another. I think trying to cross-package is a very hard task (unless you simply create a bare archive (tar, zip, etc...) - or using a CPACK variable to avoid having fakeroot executed seems awkward to disable black magic with another black magic spell. I see several workarounds/hacks: - executing with fakeroot in cpack first and in case of failure falling back to run tar without fakeroot - detect if the current user is root already Detecting if user is already root doesn't seems to be such a big hack it should even be robust as well and should be a 2 line modfication in CPackDeb.cmake protecting it even detecting FAKEROOT alltogether. -- Eric -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CPack] CPackDeb and fakeroot
2015-08-26 0:56 GMT+02:00 Raffi Enficiaud raffi.enfici...@mines-paris.org: [...] I see several workarounds/hacks: - executing with fakeroot in cpack first and in case of failure falling back to run tar without fakeroot - detect if the current user is root already Detecting if user is already root doesn't seems to be such a big hack it should even be robust as well and should be a 2 line modfication in CPackDeb.cmake protecting it even detecting FAKEROOT alltogether. Right, but I am more concerned about the proper way of doing it and not the difficulty. From all this discussion, using fakeroot directly does not look to me as the right solution for having root in the tar, in the first place. So if we are also able to get rid of the fakeroot machinery in cpack, maybe it would be a better solution. I agree, then the question is should every deb package built by CPack being owned by root? Currently people making deb with CPack without having fakeroot installed get their package with current user owning. i.e. fakeroot is not ALWAYS used. Now if you find a way to set root ownership in archive created by CPackDeb then every deb package will have those right. My opinion (from the various bug report related to deb ownership) is that is OK since creating a deb including whatever non-root user in it is a mistake. So the proper way to go may be to use libarchive directly in CPackDeb to create tar in order to better control ownership of the created bits. This is definitely more work, but this looks the proper way to me. -- Eric -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] FindBZip2.cmake
On 08/25/2015 01:45 AM, Rolf Eike Beer wrote: The BZIP2_NEED_PREFIX check generates a CMakeLists.txt file that refers to the raw path given without re-escaping the backslashes. Then the check fails to configure due to the backslashes being interpreted as invalid CMake escape sequences. No, this is not the problem. That happens if FPHSA succeeds, but that fails because it can't find the library, which means the problem is actually happen before FPHSA. In that case I'm not able to reproduce the problem you're observing because the problem above is what happened when I tried it. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Replace deprecated libarchive functions
On 08/25/2015 03:05 AM, Rolf Eike Beer wrote: I may be wrong, but I would assume that these are not deprecated libarchive3 functions, but function deprecated _in_ libarchive3, no? Yes. The libarchive source has some of them slated for removal in version 4. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Default compile options
We do specify the CMAKE_BUILD_TYPE when generating the makefiles. But it still doesn't work. I forgot to mention the generator name is NMake Makefiles. Perhaps it's a bug? -Original Message- From: Brad King [mailto:brad.k...@kitware.com] Sent: Tuesday, August 25, 2015 8:53 AM To: Robert Goulet robert.gou...@autodesk.com Cc: cmake-developers@cmake.org Subject: Re: [cmake-developers] Default compile options On 08/24/2015 05:17 PM, Robert Goulet wrote: set(CMAKE_C_FLAGS_DEBUG -D_DEBUG) in a Makefile those flags are not even passed to the compiler. In the Makefile and Ninja generators the per-config flags are used only for the configuration named in CMAKE_BUILD_TYPE. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Default compile options
On 08/25/2015 09:27 AM, Robert Goulet wrote: We do specify the CMAKE_BUILD_TYPE when generating the makefiles. But it still doesn't work. I forgot to mention the generator name is NMake Makefiles. Perhaps it's a bug? Please provide a minimal/complete CMakeLists.txt file demonstrating the problem. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [CPack] CPackDeb and fakeroot
Hi Domen, Brad and CMake developers, I am trying to create my packages in Launchpad, which uses a pbuilder environment for building the packages, directly using CMake=3.3 (which contains the nice recent fixes). I got the following error when I execute the build of a source package from pbuilder: CPack Error: /build/cmake-AHTLnO/cmake-3.3travisci1/Source/CPack/cmCPackDebGenerator.cxx:483 Problem running tar command: /usr/bin/fakeroot /usr/bin/cmake -E tar czf data.tar.gz Please check /«BUILDDIR»/build_dir/_CPack_Packages/Linux/DEB/Deb.log for errors The full logs for the curious ppl may be found here: https://launchpadlibrarian.net/215456337/buildlog_ubuntu-trusty-amd64.yayi_0.8.8.1_BUILDING.txt.gz Basically in my case, the debian/rule file calls cmake and cpack to generate the deb packages. pbuilder mimics a clean build environment that is used on Launchpad for isolating the build, and I believe (not sure) it calls fakeroot under the hood. To my understanding fakeroot is a workaround to have the proper credentials in the tar of the .deb packages since the libarchive used in cmake was not allowing that at that time: - http://public.kitware.com/Bug/view.php?id=11766 - http://public.kitware.com/Bug/view.php?id=13118 - http://public.kitware.com/Bug/view.php?id=12901 I am wondering if, instead of always using fakeroot: - there is now the possibility to set the user in libarchive (even if it is the case, this would mean that cmake -E tar is able to understand those options) - if we can get rid of the fakeroot in some circumstances? eg. a variable that would avoid using the fakeroot or detecting that the user is already root - unifying the tool used for creating the tar: from the code in cmCPackDebGenerator.cxx, some compression schemes use the native tar while some others use the cmake tar. What would be the best option for you? I believe it would address this issues already in the backlog (and help ppl deploy things on Launchpad with cmake): - http://public.kitware.com/Bug/view.php?id=13700 - http://public.kitware.com/Bug/view.php?id=11766 Thanks for your feedbacks, Best, Raffi Enficiaud -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH] Extend JNI capabilities
On 08/25/2015 09:32 AM, CHEVRIER, Marc wrote: Here is a small patch to add support for: * SuSE platform specific paths for JVM lookup * IBM SDK, Java Technology Platform Thanks, applied: FindJNI: Add support for SuSE platform and IBM Java SDK http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=290b0f94 -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake's built-in support for android using nvidia nsight tegra
On Tue, Aug 25, 2015 at 09:59:14 -0500, Peter List wrote: // required to avoid run found with adb logcat extern void Java_org_libsdl_app_SDLActivity_nativeInit(JNIEnv* env, jclass cls, jobject obj); There's an SDL_android_main.c file you need to compile. I have a personal Android/NDK app here: https://github.com/mathstuf/abagames-gunroar but it needs a CMake branch (for D support), uses git-hg to clone SDL libraries, and uses a patched NDK toolchain for D support. It also only supports Ninja anyways (make probably works; untested). If you look in src/android/CMakeLists.txt, there are steps which: - install the generated library to the src/android/jni/gunroar directory; - runs ndk-build; - links the assets into place; - build the apk using ant; - adds a target for installing it to a device. The src/android/src and src/android/jni/src directories contain the SDL glue and minimal (NDK) build scripts. Shouldn't be too hard to adapt for Tegra. It certainly makes APKs which run (but then promptly crash in the D runtime). --Ben -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
