Hi CMake developers,
yesterday I created a pull request with the attached patch. It was
rejected because it was not clear, whether we should really require all
these LaTeX related binaries.
FindLATEX tries to find, and I wanted to make them all required, these
binaries:
LATEX_COMPILER
PDFLATEX_CO
Brad King wrote:
> We're still learning the process of providing imported targets from
> find modules. As evidenced by the recent trouble with FindOpenGL:
I think the 'normal' case of them is well understood, at least as evidenced
by the Qt4 and GTK2 imported targets, which are the most-complete
Thompson, KT wrote:
> It looks like the mailing list doesn't like attachments (is that
> correct?).
The attachment seems to have worked too:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/11783/focus=11829
> # These variables may optionally be set
> # to help this module
On Thu, Dec 04, 2014 at 10:32:53AM -0500, Brad King wrote:
> On 12/04/2014 10:09 AM, Erik Sjölund wrote:
> > I think it is a good idea to rename FindXerces to FindXercesC or
> > something similar, just to indicate that is about the C++
> > implementation.
>
> Thanks for pointing out the distinct i
On 12/04/2014 02:29 PM, Stephen Kelly wrote:
# GSL_INCLUDE_DIRS - Location of GSL header files.
# GSL_LIBRARIES - The GSL libraries.
>>
>> These are defined mostly as a courtesy for folks who don't use imported
>> targets yet.
>
> Yes. They are useful at least when a FindXXX doe
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=15285
==
Reported By:Braden McDaniel
Assigned To:
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=15284
==
Reported By:Braden McDaniel
Assigned To:
Thompson, KT wrote:
> Stephen Kelly wrote:
>
>>> # GSL_INCLUDE_DIRS - Location of GSL header files.
>>> # GSL_LIBRARIES - The GSL libraries.
>
>> I'm curious: Given that you provide IMPORTED targets, what would a user
>> need these variables for? Do you have a particular use-case that n
Thanks for the feedback. Sorry for the late response. I won't be able to make
another patch for another 3 weeks.
I would like to take care of some bugs first. There is a bug where GHS MULTI is
not recompiling executables and libraries, when compiling a .elf file. Also,
the generator will need t
On 12/04/2014 10:32 AM, Brad King wrote:
> Roger, as the contributor of this module do you have any reason
> not to change the name?
I've constructed a commit to perform the rename and merged to 'next'
for testing:
Modules: Rename FindXerces to FindXercesC
http://cmake.org/gitweb?p=cmake.git;a=
It looks like the mailing list doesn't like attachments (is that correct?).
Here's my updated FindGSL.cmake:
-kt
#.rst:
# FindGSL
#
#
# Find the native GSL includes and libraries.
#
# The GNU Scientific Library (GSL) is a numerical library for C and C++
# programmers. It is free softwa
On 12/04/2014 10:09 AM, Erik Sjölund wrote:
> I think it is a good idea to rename FindXerces to FindXercesC or
> something similar, just to indicate that is about the C++
> implementation.
Thanks for pointing out the distinct implementations. The module
is new in CMake 3.1 so our last chance to r
Stephen Kelly wrote:
>> # GSL_INCLUDE_DIRS - Location of GSL header files.
>> # GSL_LIBRARIES - The GSL libraries.
> I'm curious: Given that you provide IMPORTED targets, what would a user need
> these variables for? Do you have a particular use-case that needs them?
These are defined m
Brad,
Here is a repeat and reformatted version of the email I sent off list (sorry
about that). The attached file also addresses comments from Stephen Kelly
concerning IMPORTED_CONFIGURATIONS.
Brad King wrote:
> > The command "add_library(GSL::gsl UNKOWN IMPORTED)" generates
> > warnings on p
On 12/04/2014 09:42 AM, Brad King wrote:
> This fails the ExternalProjectLocal test
>
> Please take a look.
Actually there was also a problem with Utilities/Sphinx/cmake.py
that was exposed by this change. I've fixed that:
Utilities/Sphinx: Fix link targets for mixed-case command names
http:/
As there are two implementations of Xerces, one in C++
http://xerces.apache.org/xerces-c/
and one in Java
http://xerces.apache.org/xerces-j/
I think it is a good idea to rename FindXerces to FindXercesC or
something similar, just to indicate that is about the C++
implementation.
cheers,
Erik S
On 12/03/2014 03:38 PM, Brad King wrote:
>> Is it ok if I merge it to next?
>
> Yes.
This fails the ExternalProjectLocal test with:
CMake Error at cmake_install.cmake:42 (file):
file INSTALL cannot copy file
".../Tests/ExternalProjectLocal/CMakeExternals/Build/TutorialStep5-Local-TestExc
On 12/04/2014 05:16 AM, Alin Marin Elena wrote:
> I try to use findMPI with the new intel mpi 5.0.2 and their compilers.
> Unfortunately it seems to fail to correctly find the include paths.
There is also discussion of that here:
FindMPI.cmake fails to properly detect Intel MPI 5.0.1
http://www
Hi,
I try to use findMPI with the new intel mpi 5.0.2 and their compilers.
Unfortunately it seems to fail to correctly find the include paths.
what I see at the moment
[10:07:03 alin@abaddon:~/playground/findmpi/a]: FC=mpiifort cmake ../
-- The Fortran compiler identification is Intel
-- Check fo
found this old bug related to the same thing...
https://www.cmake.org/Bug/view.php?id=12548#c27706
... and the fix?
http://www.cmake.org/gitweb?p=cmake.git;a=commitdiff;h=23381d83
On Wed, Dec 3, 2014 at 1:41 PM, Mantis Bug Tracker <
man...@public.kitware.com> wrote:
>
> The following issue has be
20 matches
Mail list logo
