> There is no need for a .src.rpm when you don't embed the build rules into it.
> However, that only makes sense for distributions that have a package
> maintainer for the software,
> creates a source package with all build options and distribution adaptions.
Have you got any more ideas for the f
On Nov 10, 2014, at 5:03 PM, cgorac wrote:
>
> Rolf Eike Beer wrote
>> Yes, but the preferable solution would be that you ship a
>> OpenBLASConfig.cmake
>> with your installation, so it would work with any CMake version and you
>> can
>> adapt that file yourself in case of new components, lib
Am 10. November 2014 21:45:26 MEZ, schrieb SF Markus Elfring
:
>Hello,
>
>Software package formats like DEB and RPM can help to distinguish
>the provided contents between source and binary files.
>https://wiki.debian.org/SourcePackage
>http://www.rpm.org/max-rpm/s1-rpm-miscellania-srpms.html
Th
Rolf Eike Beer wrote
> Yes, but the preferable solution would be that you ship a
> OpenBLASConfig.cmake
> with your installation, so it would work with any CMake version and you
> can
> adapt that file yourself in case of new components, library locations or
> other
> things.
Why would OpenBL
Hello CMake Team,
I would like to know how to import Visual studio project properties using
CMAKE? And what is the equivalent command for element in CMake?
Below is the section in the *.vcxproj file where I am importing
General_Project_Properties.props file.
Example :
T
Hello,
Software package formats like DEB and RPM can help to distinguish
the provided contents between source and binary files.
https://wiki.debian.org/SourcePackage
http://www.rpm.org/max-rpm/s1-rpm-miscellania-srpms.html
How can I achieve a corresponding distinction with CPack?
http://www.cmake
On 11/10/2014 07:50 PM, SF Markus Elfring wrote:
>> I actually don't know if this is an omission or a deliberate design choice.
> How often do use DEB and RPM package generation with CPack for your software?
>
> Regards,
> Markus
I used it quite often (only rpm), but having said that: I had a need
> I actually don't know if this is an omission or a deliberate design choice.
How often do use DEB and RPM package generation with CPack for your software?
Regards,
Markus
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_F
> You could, as a workaround for the problem, define a add_custom_target
> that removes the corresponding rpm/deb packages and just calls 'cmake
> --build --target package' to regenerate them.
Thanks for your suggestion.
> It's not an ideal solution, but it worked just fine for me.
Does this fe
On 11/10/2014 07:40 PM, SF Markus Elfring wrote:
>> You could, as a workaround for the problem, define a add_custom_target
>> that removes the corresponding rpm/deb packages and just calls 'cmake
>> --build --target package' to regenerate them.
> Thanks for your suggestion.
>
>
>> It's not an ideal
On 11/09/2014 08:34 PM, SF Markus Elfring wrote:
> Hello,
>
> I configured a specific software to use the CPack modules to generate
> corresponding DEB and RPM packages together with CMake 3 a while ago.
>
> I notice now that package specifications and control files contain
> outdated version data
On 11/10/2014 07:44 AM, Nicholas Yue wrote:
Hi,
Using CMake 2.8.12.2 on Windows 7 x64 with Visual Studio 2012
WDExpress, my include_directories() information are being embedded in
the AdditionalOptions part of the generated *.vcxproj XML file instead
of the AdditionalIncludeDirectories part
On 11/10/2014 06:32 AM, Nicholas Yue wrote:
I am improving an in-house Find*.cmake and need to determine
(programmatically) where it (the Find*.cmake file) is located because I
need to run a companion python script. Is there some variable I can query ?
CMAKE_CURRENT_LIST_DIR for the full pat
13 matches
Mail list logo