Hi Folks,
It turns out the "export(PACKAGE ..)" does NOT have issue, the problem was
that the value I associated with _DIR was incorrect and since
a package had been exported earlier, CMake found one despite
the fact an error would have been expected.
I guess it would make sens to add an option
Hello,
On 28/03/13 22:28, David Cole wrote:
> I, too, live in the real world, in addition to having my theories about
> it... :-)
>
> And, for what it's worth, I'd rather add a project config file to any
> project out there that would accept code contributions from me than add
> yet another fi
Qt is actually the perfect example of this. Stephen Kelly has done a
superb job getting project config files working with Qt 5. That's right
-- you can actually do a find_package of Qt for Qt 5 with an existing
CMake release, *without* having a FindQt5.cmake file in CMake itself.
It's awesome!
On 3/28/2013 5:28 PM, David Cole wrote:
I, too, live in the real world, in addition to having my theories about
it... :-)
And, for what it's worth, I'd rather add a project config file to any
project out there that would accept code contributions from me than add
yet another find module into CMa
I, too, live in the real world, in addition to having my theories about
it... :-)
And, for what it's worth, I'd rather add a project config file to any
project out there that would accept code contributions from me than add
yet another find module into CMake.
Obviously, there will be cases w
If _DIR is given and has a correct value, it is a bug if
find_package finds the project anywhere else. Whether that's generally
true or not, I sort of doubt it. It probably depends on the project
itself, and the find and/or config files involved.
I second Stephen's request for steps to reprodu
On 2013-03-28 16:41- Miller Henry wrote:
[...] I have to deal with the real world where many projects don't
provide a project config .cmake script. They see no reason to: they
don't build with cmake, other downstreams don't build with cmake. It
seems to them that they are supporting one sy
Jean-Christophe Fillion-Robin wrote:
> Hi Folks,
>
> I would like to discussed the usable of "export(PACKAGE ...)" statement.
>
> Based on my experience, it turns out that exporting the build tree in the
> system package registry is a bad idea when building the same package
> multiple time as it
On 2013-03-28 16:02, Chris Stankevitz wrote:
On Tue, Mar 19, 2013 at 3:13 AM, Ansis Māliņš wrote:
Q: Can cmake automatically not build "b" when "a" is not available?
find_package(a)
if(a_FOUND)
ExternalProject_Add(b PREFIX blabla ...)
endif()
Hello,
If I understand correctly, this is
Hi Folks,
I would like to discussed the usable of "export(PACKAGE ...)" statement.
Based on my experience, it turns out that exporting the build tree in the
system package registry is a bad idea when building the same package
multiple time as it is done on a dashboard client or a developer
workst
On Tue, Mar 19, 2013 at 3:13 AM, Ansis Māliņš wrote:
>>
>> Q: Can cmake automatically not build "b" when "a" is not available?
>
> find_package(a)
> if(a_FOUND)
> ExternalProject_Add(b PREFIX blabla ...)
> endif()
Hello,
If I understand correctly, this is what just happened:
Chris: Is there
On 2013-03-28 13:26-0400 Jean-Christophe Fillion-Robin wrote:
Hi Alan,
You could look at: https://github.com/davidsansome/python-cmake-buildsystem
More particularly this commit:
- Export targets from both the installed and build tree [1]
- Add generation of Config.cmake [2]
[1]
https://gith
On 3/28/2013 2:19 PM, Martin Koller wrote:
I'm doing this with a toolchain file, so that cmake sees this as
cross-compiling.
E.g. I have the following toolchain file "linux_i686.toolchain.cmake":
# toolchain file for building a 32bit version on a 64bit host
# use it like this:
# cmake -DCMAKE
On Wednesday 27 March 2013 10:37:12 Nicola Mori wrote:
> Hello, for my project I'd like to be able to configure a 32 bit build
> with GCC in a 64 bit Linux environment by setting variables from command
> line interface. As far as I understand of CMake, this can be
> accomplished by setting CMAKE
On 3/28/2013 1:17 PM, Alan W. Irwin wrote:
All projects should provide a "project config file .cmake script"
readable by CMake's find_package, and installed in a location where
CMake can find it, so that a CMake find module is completely unnecessary.
Hi David:
Your idea sounds like a good one,
Nice theory, but I have to deal with the real world where many projects don't
provide a project config .cmake script. They see no reason to: they don't build
with cmake, other downstreams don't build with cmake. It seems to them that
they are supporting one system, and there are hundreds. I do
Hi Alan,
You could look at: https://github.com/davidsansome/python-cmake-buildsystem
More particularly this commit:
- Export targets from both the installed and build tree [1]
- Add generation of Config.cmake [2]
[1]
https://github.com/davidsansome/python-cmake-buildsystem/commit/73134d77881
On 2013-03-28 12:25-0400 David Cole wrote:
CMake needs no new Find modules.
All projects should provide a "project config file .cmake script" readable by
CMake's find_package, and installed in a location where CMake can find it, so
that a CMake find module is completely unnecessary.
Hi Davi
+1
On Thu, Mar 28, 2013 at 12:25 PM, David Cole wrote:
> CMake needs no new Find modules.
>
> All projects should provide a "project config file .cmake script" readable
> by CMake's find_package, and installed in a location where CMake can find
> it, so that a CMake find module is completely un
CMake needs no new Find modules.
All projects should provide a "project config file .cmake script"
readable by CMake's find_package, and installed in a location where
CMake can find it, so that a CMake find module is completely
unnecessary.
For other types of module improvements, I think bec
I upgraded, but no luck. Fortunately, I figured it out and it was fairly
simple (I really should have thought of this before posting to the mailing
list!).
I decided to go through with the conversion to see what VS 2010 was having
problems with. It turns out that only one of the projects required
What about trying CMake 2.8.11rc1 ?
See http://www.kitware.com/blog/home/post/462
On Thu, Mar 28, 2013 at 10:47 AM, Zamir Khan wrote:
> Good idea, but unfortunately the same results with the 32-bit version. And
> yes, it is VS 2010 Professional. CMake is version 2.8.10.2.
>
>
>
> --
> View this
Good idea, but unfortunately the same results with the 32-bit version. And
yes, it is VS 2010 Professional. CMake is version 2.8.10.2.
--
View this message in context:
http://cmake.3232098.n2.nabble.com/Conversion-Wizard-for-VS-2010-tp7583820p7583826.html
Sent from the CMake mailing list archiv
You could try to generate the 32-bit version of your project and see if
VS2010 works as expected. Do you confirm you have the Pro version of VS2010
?
Hth
Jc
On Thu, Mar 28, 2013 at 10:37 AM, Zamir Khan wrote:
> Yes, with all due respect, that is pretty basic (although I understand
> that there
Hi,
By default solution files are probably associated with VS2008, did you make
sure you were starting VS2010, then doing File -> Open and selecting the
generated solution files ?
Hth
Jc
On Thu, Mar 28, 2013 at 10:18 AM, Zamir Khan wrote:
> I re-did this just to confirm and yes, I start with
Yes, with all due respect, that is pretty basic (although I understand that
there could easily be something basic going wrong here). To open the
solution file, I open Visual Studio 2010 from the windows start menu and
then use the File > Open > Project / Solution option to select the
generated sln
I re-did this just to confirm and yes, I start with a new, empty directory
and choose "Visual Studio 10 Win64" as the generator and "Use default native
compilers". If I choose "Visual Studio 9 Win64", I can open the solution in
VS2008 without issues.
--
View this message in context:
http://cmak
Hi Zkhan,
Do you confirm that you configured your project in an empty new directory ?
Hth
Jc
On Thu, Mar 28, 2013 at 10:00 AM, zkhan wrote:
> I am trying to migrate a fairly large project from VS 2008 to VS 2010.
> However, when I use CMake to generate the "Visual Studio 10 Win64" solution
>
I am trying to migrate a fairly large project from VS 2008 to VS 2010.
However, when I use CMake to generate the "Visual Studio 10 Win64" solution
(my target platform is Windows 7, x64) and try to open the solution in VS
2010, I am prompted by the conversion wizard, which I assume should not
happen
On 3/27/2013 9:48 PM, William Clodius wrote:
I have been developing Fortran 2003 code on a Mac system. Because
Xcode comes with a very old version of gcc its Fortran compiler has
poor support for newer versions of Fortran, so I have been using
newer versions of gcc installed using Mac Fink, and r
Hi,
To CMake maintainers,
what do you think about creating new repository at
https://github.com/Kitware/CMakeModules
as incubator for contributed CMake modules?
Here is outline of the process I'm thinking of:
1. I have developed new module for find_package
2. I submit pull request adding this
31 matches
Mail list logo
