On Mon, Aug 27, 2018 at 12:43 PM Brad King wrote:
> On 08/25/2018 05:48 PM, Richard Shaw wrote:
> > set(CMAKE_EXE_LINKER_FLAGS "-T${CMAKE_SOURCE_DIR}/stm32_flash.ld")
> >
> > The build dir is the binary directory, not the source directory...
>
> Toolchain
On Thu, Aug 23, 2018 at 11:58 AM Brad King wrote:
> On 08/22/2018 04:23 PM, Richard Shaw wrote:
>
> Meanwhile you can use just
>
> set(CMAKE_EXECUTABLE_SUFFIX ".elf")
>
Ok, interestingly that had no effect, but if I moved the
set(CMAKE_EXECUTABLE_SUFFIX_) to the ma
On Wed, Aug 22, 2018 at 3:02 PM Brad King wrote:
> On 08/22/2018 03:49 PM, Richard Shaw wrote:
> > Initially I tried setting the flags before invoking "project" and that
> seemed
> > to be enough for Fedora. I've tried other things as well that I've
> pr
On Wed, Aug 22, 2018 at 1:51 PM Brad King wrote:
> On 08/21/2018 03:18 PM, Richard Shaw wrote:
> > without --specs=nosys.specs applied during compiler testing, cmake fails.
>
> How is this flag specified when invoking CMake?
>
Initially I tried setting the flags before invo
I have a cross platform project that I have building correctly for the
STM32 platform on Fedora but everyone using Ubuntu is having problems.
Basically, without --specs=nosys.specs applied during compiler testing,
cmake fails. I have reports of this happening on Ubuntu 14.x, 16,x and have
setup a
I'm working on a cross-compiling project for the STM32F4 arm processor and
on my Fedora 28 system everything is working fine (cmake 3.11.2) but others
trying to configure are running into problems with the compiler check
failing.
Since I'm cross-compiling as far as I know I need "--specs=nosys.spe
On Wed, Dec 9, 2015 at 7:32 AM, Igor Sobinov wrote:
> Hello,
>
> I compiled cmake based project with -jN option, but failed: I got the
> following error:
>
> make[4]: warning: jobserver unavailable: using -j1. Add `+' to parent
> make rule.
>
> How to make cmake to compile with multiple targets?
On Thu, Jul 9, 2015 at 3:09 PM, Bob Bachman
wrote:
>
> It's defined in the CMakeLists.txt file and stored in the CMakeCache.txt
> file.
>
> //Path to a program.
>
> wxWidgets_CONFIG_EXECUTABLE:FILEPATH=/home/mzx_bldr/mozaix_svn/engineering/c
> ommon_src/src/wxWidgets-3.0.2/buildgtk/wx-config
Ok
On Thu, Jul 9, 2015 at 2:32 PM, Bob Bachman
wrote:
> Richard Shaw writes:
> > Ok, so that's not what's going on... Is this a custom build of wxWidgets?
> Is wx-config located in /usr/bin or somewhere else?
>
> We build wxWidgets here. It's not located in /us
On Thu, Jul 9, 2015 at 2:10 PM, Bob Bachman
wrote:
> Richard Shaw writes:
> > On Thu, Jul 9, 2015 at 1:19 PM, Bob Bachman jxeu3b3ms+tby3ivrkz...@public.gmane.org> wrote:We've upgraded from
> wxWidgets
> 2.8.10 to 3.0.2 and our CMake scripts can no
> > longer fin
On Thu, Jul 9, 2015 at 1:19 PM, Bob Bachman
wrote:
> We've upgraded from wxWidgets 2.8.10 to 3.0.2 and our CMake scripts can no
> longer find the required wxWidgets libs. The wxWidgets shared object files
> have been built and exist in the same directory structure as the 2.8.10
> version. Any hel
I've got a cmake based project that can optionally build static versions of
most of its dependencies and it works fine on Linux and MSYS2+MinGW.
The problem is when I try to cross compile using MinGW on Linux. I would
expect cmake would be smart enough to know if the parent project is being
built
On Mon, Dec 15, 2014 at 3:52 AM, Johannes Zarl wrote:
>
> Hello Robert,
>
> I don't have a test-environment handy, but it seems like FindwxWidgets
> checks
> for the vc_x64 library directory prefix, not for vc_amd64:
>
> # /usr/share/cmake-3.0/Modules/FindwxWidgets.cmake:511:
> if(MINGW)
>
I'm packaging a library using the NSIS CPack installer and it does not have
any executables which require start menu links so needless to say I don't
need any desktop links.
I do want the end user to have the ability to add the location to the path
so I have that enabled but it includes a check bo
Is it currently possible to build a VB project with cmake? I can't seem to
find any references to do so. I'm planning on using the bvnc compiler from
the mono package for linux.
Thanks,
Richard
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.c
I figured it out...
I'm cross-compiling MinGW on Fedora linux and it just dawned on me that the
cmake instance run by CPack probably isn't using the correct environment. I
think it would be best if this was handled automatically but for the time
being I pushed the required variables into the insta
Ok, I have no idea what's going on.
I'm using configure_file to put the get_preresiquites cmake script in the
binary dir...
It's running...
It's not show any errors...
It's also not finding any dependencies...
I've double and triple checked that the variable I'm using in the message
command is t
Ok, this may or may not work but I figured it was worth a try.
I'm running out of motivation to get a good method to determine which DLL's
I need to package with the install(SCRIPT...) / GetPrerequisites mess.
My current approach is to attempt to use try_compile to build a minimal
program I can l
On Sat, Sep 20, 2014 at 12:40 PM, Iosif Neitzke <
iosif.neitzke+cm...@gmail.com> wrote:
> Which defines, for example?
I'm not sure why it matters but the projects maintains it's own nsis config
file and in there is expects that the binaries which are being packaged
(could be one, or the other, o
In my continued efforts to convert a project from autotools to CMake I've
gotten to the point of creating an NSIS package.
I'm trying not to modify any existing source files and the current method
passes some defines to the nsis binary but I can't see any way to do that
with the available CPACK va
On Thu, Sep 11, 2014 at 9:51 AM, Vojtech MaĊĦek wrote:
> Hi, I am working at team developing RPM pacage generator.
> Now I am solving a problem how can i get dependencies using cmake.
> Basically we need to get paths to libs like they are cached in
> CmakeCache.txt, is it somehow possible before c
Am I doing something wrong or is this a known bug?
I have a list of about 5 headers, CODEC2_PUBLIC_HEADERS.
I used set_target_properties( PROPERTIES PUBLIC_HEADER
${CODEC2_PUBLIC_HEADERS})
then in the install target I added:
PUBLIC_HEADER DESTINATION ${CMAKE_INSTALL_INCLUDEDIR}/codec2
When I do
I'm hoping I'm just missing something really obvious but I recently
discovered the module GNUInstallDirs which is great. But I just tried
converting over to it on one of my projects and although my system is
definitely x86_64 the libraries are getting installed to lib not lib64.
I looked through t
Thanks for the responses everyone.
I'm just volunteering to change the build system on one of my favorite
pieces of software so I don't know the code inside and out. As far as I
know linux, windows, freebsd and OSX are supported for *running* but I
believe the windows version is cross-compiled fro
In the project I'm converting to cmake there are a lot of checks for
headers and functions I've reimplemented in cmake, but it seems a lot of
autotools based programs do a lot of excessive checking and I don't want to
implement stuff that can be safely assumed on most systems.
Here's a snippet of
On Thu, Aug 28, 2014 at 4:07 PM, Kornel Benko wrote:
> Am Donnerstag, 28. August 2014 um 15:47:06, schrieb Richard Shaw <
> hobbes1...@gmail.com>
> > On Thu, Aug 28, 2014 at 3:39 PM, Kornel Benko wrote:
> >
> > > You use '-DHAVE_CONFIG_H
On Thu, Aug 28, 2014 at 3:39 PM, Kornel Benko wrote:
> You use '-DHAVE_CONFIG_H', this means probably generated 'config.h'.
> Differences between generation of this file of automake/cmake?
>
> Could be but I think I found most of those. I tried browsing through the
code and I didn't see any #if's
I'm working on converting a project[1] from autotools to CMake and I've
gotten a lot of it working. The project HEAVILY relies on values from a
config.h but I think I've gotten the essentials covered although it took a
while.
Currently the build is failing on the following:
[ 23%] Building CXX obj
On Mon, Aug 25, 2014 at 4:10 PM, Jean-Christophe Fillion-Robin <
jchris.filli...@kitware.com> wrote:
> Hi Richard,
>
> Generator expression won't work in install rules. Instead, I suggest you
> simply use "install(TARGET ...") for regular targets.
>
That explains that problem. I'm not sure if you
Ok, apparently I'm the only person that can't figure out how generator
expressions work but I worked around it using "find_program" to find the
resultant executable in the source directory, which I think is a really bad
way to do it, but it works.
Then I use find_library to get the full path of th
Ok, short answer to #1, no you can't use install(CODE because all your
cmake variables we be evaluated now instead of later.
Same problem though when I use install(SCRIPT...
Run CPack packaging tool...
CPack: Create package using NSIS
CPack: Install projects
CPack: - Run preinstall target for: Fr
Ok, that being the case I tried it out. There's two things I'm doing
differently than the only example[1] I found:
1. Using install(CODE...) instead of install(SCRIPT...), shouldn't work any
differently, right?
2. The example is from 2009 and uses:
GET_TARGET_PROPERTY(MY_BINARY_LOCATION my_binary
On Tue, Aug 19, 2014 at 11:40 AM, Hendrik Sattler
wrote:
>
>
> On 19. August 2014 16:36:14 MESZ, David Cole via CMake
> wrote:
> >> Definitely getting warmer! It looks like that GetPrerequistes only
> >> works on an existing target so I'm thinking I would have to set this
> >> up as a "super" cm
I have a project where I currently have a dumb list of libraries to package
with the NSIS installer so the program will work under win32. It really
only works for one setup (currently Fedora mingw) with some prebuilt
libraries downloaded, others provided through Fedora, and others I build
myself. T
I converted a project from autotools/handmade makefiles to cmake and
afterwards I added NSIS packaging for win32 builds via the cpack
integration.
Everything was fine while the version patch level was being used, but upon
the next release "0.97" w/o a patch level the resultant installer has the
sh
Ok, I didn't notice my replies going to Norman only, apologies.
Answer from upstream is that it returns true if the target exists, it does
not care from a ExternalProject POV that the target has been built. The
documentation has been clarified.
I have it working properly now testing for the exist
On Thu, Dec 12, 2013 at 11:20 AM, Williams, Norman K <
norman-k-willi...@uiowa.edu> wrote:
> This is a case for ExternalProjects.
> http://www.kitware.com/media/html/BuildingExternalProjectsWithCMake2.8.html
I've read that before but didn't find anything new there. I also tried
checking the stat
I've had this working and I don't *THINK* I changed anything that would
cause it to fail now but I'm not completely sure.
I have a project I converted over to cmake from automake which requires
wxWidgets 3.0 (or the 2.9 devel branch). Although it just released I still
want to maintain the ability
On Fri, Oct 18, 2013 at 6:34 AM, Olaf Ryder wrote:
> Here's the problem I'm trying to solve:
>
> * External Project A has no dependencies and generates LibraryA
> * External Project B is dependent on LibraryA
>
I worked around a similar issue to this with a project that required
wxWidgets, which
I have a project I successfully built under mingw32 and I'm now attempting
to build under mingw64.
I am cross compiling under Fedora x86_64...
In order to pull in all the DLLs for CPack I devised the following:
# Try to grab all the runtime dlls for the windows installer.
# This will bre
Ack, something about this list confuses gmail and it always goes to the
poster instead of the list apologies.
On Fri, Jun 14, 2013 at 1:07 AM, J Decker wrote:
> I think something like
> if( NOT UNIX )
> install( TARGETS x RUNTIME DESTINATION bin
>LIBRARY DESTINATION bin
>ARCHIVE DESTINAT
On Wed, Jun 12, 2013 at 2:30 PM, William McKenzie
wrote:
> Just wondering what the common convention is here. If I have some
> generated c/c++ source files, say from gSoap or Lex/Yacc (and my build
> rules take care of the generation), is the convention to generate these
> into the build folder,
On Mon, Jun 10, 2013 at 2:06 PM, Matthew Woehlke <
matthew.woeh...@kitware.com> wrote:
> On 2013-06-10 04:52, setareh S wrote:
>
>> Now, I want to build my code for Linux platform(GNU/Linux) on a Win32
>> platform. I tried doing the above procedure using CMake combined with
>> Cygwin and using gcc
I'm working on converting a small project from autotools to cmake and one
of the final nit-pick issues is that the version of the software is defined
in a file, version.h as #defines.
I haven't been able to find the magic incantation of file(READ...,
string(REGEX MATCH... to parse the version numb
44 matches
Mail list logo
