[cmake-developers] [CMake 0012141]: Add Debian Source Generator Module
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=12141 == Reported By:Rosen Diankov Assigned To: == Project:CMake Issue ID: 12141 Category: (No Category) Reproducibility:N/A Severity: feature Priority: normal Status: new == Date Submitted: 2011-04-30 05:50 EDT Last Modified: 2011-04-30 05:50 EDT == Summary:Add Debian Source Generator Module Description: We just finished a new debian source package generator script for cmake: https://openrave.svn.sourceforge.net/svnroot/openrave/trunk/modules-cmake/DebSourcePPA.cmake This is based on the initial UploadPPA.cmake file ( http://purplekarrot.net/blog/dputCMake.html ) by Daniel Pfeifer, except it adds 4 new cool features: 1. Simultaneous output of multiple debian source packages for each distribution. Users can specify them by set(CPACK_DEBIAN_DISTRIBUTION_RELEASES karmic lucid maverick natty) and 4 dsc files, 4 changes files, 4 debian.tar.gz files, and one src.orig.tar.gz file will be outputted. These can be sent directly to launchpad via dput 2. Automatically generates symbols and run-time dependencies from the build dependencies 3. Custom copy of source directory via CPACK_DEBIAN_PACKAGE_SOURCE_COPY 4. Handles distro and release specific dependencies through: DEPENDS_DISTRO_RELEASE, DEPENDS_DISTRO, DEPENDS. For example: CPACK_DEBIAN_PACKAGE_DEPENDS_UBUNTU_LUCID The usage of this file for generating packages for the OpenRAVE project can be seen here: https://launchpad.net/~openrave/+archive/release/+packages == Issue History Date ModifiedUsername FieldChange == 2011-04-30 05:50 Rosen Diankov New Issue 2011-04-30 05:50 Rosen Diankov File Added: DebSourcePPA.cmake == ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Better Eclipse CDT support
On Saturday 30 April 2011, Oliver Buchtala wrote: Am 29.04.2011 21:45, schrieb Manuel Klimek: On Fri, Apr 29, 2011 at 11:55 AM, Alexander Neundorf neund...@kde.org wrote: On Thursday 28 April 2011, Oliver Buchtala wrote: ... wst-file is allright and I see that all projects are generated :) Unfortunately, this working set stuff is yet a bit inconvenient, as it is not an Eclipse built-in. What you need to do: 0. Switch to C/C++ perspective (maybe this is the empty project observation you described?) 1. Import eclipse projects (all from the CDT_ECLIPSE_OUTPUT_DIR) - you see all projects flat side by side? I have to import all the projects in eclipse/ manually one by one ? Nope, you just go to the toplevel directory, and eclipse will import recursively. Ah, I didn't know that. I want to create an Eclipse Plugin which shall make all this more convenient and more automatically. Something like a CMake enabling 'Solution' file that manages imported projects and working sets etc... But yet I am a PDE beginner... so, this will take some more weeks... That sounds like a great plan :-) But, for me, the thing which sucks by far most about the Eclipse generator, is that Eclipse has these problems with out-of-source building. AFAIK Eclipse expects that the project file is at the root of the source tree, and that e.g. also the svn etc. directories are in this tree. Nowadays, there are ways to deal better with that: linked folders, virtual folders and linked resources I'm not using Eclipse actively myself, I'm just maintaining the generator. But what people told me is that if the sources are not in a subdir of the project file, then the svn support of Eclipse does not work. Also if the sources are in a linked folder. Did this change ? For me Oliver's eclipse generator actually works with out-of-source builds. (eclipse 3.7, CDT 8). If I remember correctly the main thing to look out for is to put the workspace outside of both the source and the cmake build directory. Actually, *only* out-of-tree works well - unfortunately even (out-of-tree)^2 is necessary ;) The proposed solution is pretty similar to that generated for Visual Studio using virtual folders for structure and explicit referenced files. There are two options when importing generated eclipse projects: 1. Create out-of-every-tree using CDT_ECLIPSE_OUTPUT_DIR, then easy import by one click (ehm... at least O(1)) ;) 2. do not use CDT_ECLIPSE_OUTPUT_DIR? then make sure you copy the projects into your workspace (by activating a checkbox in the dialog). Though, I do not recomment as reconfigure won't affect your projects then. Unfortunately the following is not working (would be my favorite): proj-root - src ... - build - eclipse-prj - eclipse-linked folder to proj-root/ together with using proj-root/build as eclipse workspace. It is not allowed to have 'active' projects in some sub-dir of linked folders, or in other words, to link to parent-folders from eclipse proj. So how should the directory layout look like ? I currently do SOMEDIR/foo-src/ SOMEDIR/foo-build/ and there your new generator creates a SOMEDIR/foo-build/eclipse/ directory. Alex ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0012142]: Read-only files lose their read-only attribute when packaged using either ZIP or NSIS
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=12142 == Reported By:Alan Assigned To: == Project:CMake Issue ID: 12142 Category: CPack Reproducibility:always Severity: major Priority: high Status: new == Date Submitted: 2011-04-30 18:52 WAT Last Modified: 2011-04-30 18:52 WAT == Summary:Read-only files lose their read-only attribute when packaged using either ZIP or NSIS Description: To package a read-only file using CMake/CPack works as expected on Linux (using TGZ) and Mac OS X (using either PackageMaker or ZIP), but not on Windows (either using ZIP or NSIS). Steps to Reproduce: To reproduce the problem: - Unzip the attached Test.zip file; - Either: - Double click on the packageproj.bat file; or - Open a command prompt window, cd to the directory where you unzipped the file, and execute the packageproj.bat file from the command prompt; - Execute [Test]\build\Test-0.1.1-win32.exe and/or unzip the [Test]\build\Test-0.1.1-win32.zip file; - Go to the installation/unzipped folder and check the permissions for our deployed readOnlyFile.txt file. Expected result: our deployed readOnlyFile.txt file should be readable only. Actual result: our deployed readOnlyFile.txt file is read-writable. Additional Information: If you were to test the above on either Linux or Mac OS X (using, for example, the packageproj shell script which is provided), you would see that our deployed readOnlyFile.txt file is readable only, as expected. Otherwise, it might be worth pointing out that, on Windows and for NSIS and ZIP respectively, [Test]\build\_CPack_Packages\win32\NSIS\Test-0.1.1-win32\readOnlyFile.txt and [Test]\build\_CPack_Packages\win32\ZIP\Test-0.1.1-win32\readOnlyFile.txt are read-only. So, could it be that the problem is during the packaging itself? It certainly looks like it. From a reply I got on the mailing list, it would seem that the same libarchive is used for ZIP on the different platforms (see http://www.cmake.org/pipermail/cmake/2011-April/044124.html). Still, I get the feeling that the problem might still be there (as we know, permissions are handled in a very different way on Windows compared to Linux / Mac OS X, so...?). Finally, regarding NSIS, having checked the contents of [Test]\build\_CPack_Packages\win32\NSIS\project.nsi, it seems to me that the NSIS project file misses a call to SetFileAttributes with READONLY as a parameter. This would ensure that once deployed, our readOnlyFile.txt is indeed read-only. At least, this is what I had to do for another project of mine for which I had to 'manually' write a NSIS project file. == Issue History Date ModifiedUsername FieldChange == 2011-04-30 18:52 Alan New Issue 2011-04-30 18:52 Alan File Added: Test.zip == ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Better Eclipse CDT support
Am 30.04.2011 19:56, schrieb Oliver Buchtala: Am 30.04.2011 19:29, schrieb Alexander Neundorf: Nowadays, there are ways to deal better with that: linked folders, virtual folders and linked resources I'm not using Eclipse actively myself, I'm just maintaining the generator. But what people told me is that if the sources are not in a subdir of the project file, then the svn support of Eclipse does not work. Also if the sources are in a linked folder. Did this change ? Ok. Don't know. I have to check... Actually, there happened a lot around folders. Maybe this also works in the meantime. Nope. This is still not supported. My personal opinion is that I do not care about eclipse svn support. Other IDEs don't support this either (or not well). Also, in earlier days I have had not too good experiences with Subversive and Subclipse and always returned to doing svn from command line or other tools (e.g. TortoiseSVN). I looked a bit around in the internet and still find mainly bad remarks for those both plugins and suggestions not to do it from within Eclipse. Bye, Oliver ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
