The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=15707
==
Reported By:Daniel Levin
Assigned To:
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=15706
==
Reported By:ovz
Assigned To:
I would like to submit a new patch to write the PackageCertificateThumbprint
tag in VS projects for Windows Phone and Windows Store projects.
When creating a Windows Store project, a certificate is added to the package.
There is a PackageCertificateThumbprint tag that VS will write when absent t
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.
On 08/21/2015 10:58 AM, Ben Boeckel wrote:
> CMake would have to ship with multiple versions of Boost, each subsetted
> and likely patched. That is hardly better.
This falls under the category of third-party libraries that are
candidates for use in the already-proposed cleanup of KWSys:
On 08/21/
On Fri, Aug 21, 2015 at 10:35:58 -0400, David Cole via cmake-developers wrote:
> Honestly, KWSys has always seemed like a boost-avoidance mechanism
> from an outsider's perspective. Perhaps it should be replaced with
> boost equivalents in projects that need to be packaged for Fedora.
>
> I assume
Honestly, KWSys has always seemed like a boost-avoidance mechanism
from an outsider's perspective. Perhaps it should be replaced with
boost equivalents in projects that need to be packaged for Fedora.
I assume all the boost libraries are already packaged/available.
Fuel for the fire, ;-)
D
On
On 08/18/2015 02:57 AM, CHEVRIER, Marc wrote:
> Unfortunately I don't have access to an HP-UX system.
For reference, we worked out the problem off-list with someone
that has access to HP-UX. The fix is:
HP-UX: Do not use ".sl" extension for shared libs on Itanium
http://cmake.org/gitweb?p=cmak
On 08/19/2015 03:46 PM, Gregor Jasny via cmake-developers wrote:
> The problem I see with this approach is that CMake provides no official
> iOS toolchain file (maybe we should?). And the popular cmake-ios project
> [1] for example sets SYSTEM_NAME to Darwin.
Yes. This should be resolved by split
On 08/20/2015 10:19 PM, Orion Poplawski wrote:
> The consensus of the FPC is that the current situation with KWSys is
> very undesirable. While this approach may have been reasonable years
> ago with few consumers, it does not seem acceptable at this point.
FWIW, the origin of this is the follo
I still disagree on the point that CMake shouldn't be fixed because of possibly
erroneous external scripts that are not able to handle paths which were - again
possibly - passed to them as parameters in the style of the platform they were
written for. This is very hypothetical in my opinion. We
11 matches
Mail list logo
