I am looking to specify different DLL's to use based on it building in debug or release. for example:
IF CONFIGURATION MATCHES Debug
SET(MYDLL my_dlld)
ELSE()
SET(MYDLL my_dll)
ENDIF()
I have looked at logical expressions such as
$<$<CONFIG:Debug>:DEBUG_MODE>
But this did not seem to work, maybe my implementation of it was incorrect. Any help would be greatly appreciated
EDIT: Some minimal code for understanding
PROJECT(myproject)
#ADD_DEFINITIONS(-DMANAGER_EXPORTS)
INCLUDE_DIRECTORIES(
${CMAKE_SOURCE_DIR}/API/mydll
)
$<$<CONFIG:Debug>:SET(MYDLL mydlld)>
$<$<CONFIG:Release>:SET(MYDLL mydll)>
SET(LIBS
${MYDLL}
)
mydll - Is a pre-generated shared library which has a debug and release version
I think a possible solution is that you can do the following
#SET(LINK_LIB debug my_dlld optimized my_dll)
#TARGET_LINK_LIBRARIES(MYDLL ${LINK_LIB})
Hope this helps !
Related
Apparently anything GUI-related in terms of components involves XML. I cannot go around actually configuring and building wxWidgets from source because of that. I'm new to wxWidgets.
My current setup is on Win10 with MSVC v141 (Visual Studio 2017) with the latest CMake version (currently 3.21).
Inside the config.cmake of the wxWidgets projects (using latest master branch) I see
wx_get_dependencies(EXTRALIBS_XML xml)
I am also calling CMake with -DwxUSE_XML=ON (among other parameters) but this still leads to:
the XML dependency is nowhere to be found
respectively it's not built
Linking then fails with the following error:
LINK : fatal error LNK1104: cannot open file 'wxxml.lib' [C:\Users\...\CMakeBuilds\ef5b5ada-ee42-7735-988a-ae37c735ccff\build\deps\build\wxwidgets\libs\qa\wxqa.vcxproj]
What library is actually wxWidgets using and how do I trigger it's retrieval and accordingly configuration and building? Since I am adding wxWidgets to my CMake project as an ExternalProject component, I would appreciated something in that line of thought. However any kind of information regarding this issue is more than welcome especially since it will shine light on how to configure other features (if I want them in the future) such as WebView.
The wxxml.lib issue is fixed now. While fixing it I also discovered a bug (of sort) in the build system of wxWidgets.
The reason why it failed to build this library in particular was actually quite simple but due to the lack of knowledge in the dependencies of wxWidgets. I thought that wxWidgets, given it depends on XML so much, has its own XML parser. Well, not really. The wxXML component actually uses and underlying 3rd party dependency called EXPAT, which - as you can see in my question - I have deactivated since it was giving me issues during the build (due to the still present problem of not being able to automatically retrieve dependencies).
What I did was to clone the libexpat repository, add it as an ExternalProject, set the variables for the libraries and include directory and pass them onto my wxWidgets project. But there is a catch...
The expat.cmake file looks as follows:
#############################################################################
# Name: build/cmake/lib/expat.cmake
# Purpose: Use external or internal expat lib
# Author: Tobias Taschner
# Created: 2016-09-21
# Copyright: (c) 2016 wxWidgets development team
# Licence: wxWindows licence
#############################################################################
if(wxUSE_EXPAT STREQUAL "builtin")
# TODO: implement building expat via its CMake file, using
# add_subdirectory or ExternalProject_Add
wx_add_builtin_library(wxexpat
src/expat/expat/lib/xmlparse.c
src/expat/expat/lib/xmlrole.c
src/expat/expat/lib/xmltok.c
)
set(EXPAT_LIBRARIES wxexpat)
set(EXPAT_INCLUDE_DIRS ${wxSOURCE_DIR}/src/expat/expat/lib)
elseif(wxUSE_EXPAT)
find_package(EXPAT REQUIRED)
endif()
I would use the *.cmake files of the 3rd party dependencies stored inside <ROOT_OF_WXWIDGETS_PROJECT>/build/cmake/lib to determine which variables I need to set if builtin is selected as the value for the respective library. Since I want to use my own I need sys (e.g. -DwxUSE_EXPAT=sys as a CMAKE_ARGS inside my wxWidgets ExternalProject) and also to pass the headers and libraries accordingly.
Given the file above one would assume that EXPAT_LIBRARIES is required. However after failing to build (yet again) and seeing that the reason was the activated expat build and that it was set as builtin I checked the log in detail and found the following error:
Could NOT find EXPAT (missing: EXPAT_LIBRARY) (found version "2.2.6")
Notice the EXPAT_LIBRARY. After passing it (-DEXPAT_LIBRARY=...) my build was complete. For me this is a bug or simply inconsistency between the dependency cmake file and the rest of the wxWidgets project.
It is important to note that I do not retrieve the external dependency through wxWidgets itself (see config.cmake and more precisely the macro wx_get_dependencies(...)). This solves the problem with a basic configuration and build of wxWidgets but if you don't want to tackle every dependency of wxWidgets on your own (why should you?), I recommend looking for a solution where the dependencies (at least the ones you don't want to deal with) are automatically retrieved, configured and build as builtin.
I'm trying to compile a Windows DLL for code originally intended for a Unix platform. One problem I have is that Windows fopen() defaults to O_TEXT, but Unix defaults to O_BINARY.
Windows recommends two ways to solve this:
Use _set_fmode() function, didn't work for me probably because I could not call it from correct context.
Link with binmode.obj object file. This file is included with the compiler, and the compiler knows where to look for it.
The latter worked for my own code, but it does not seem to work for third party static libraries. Looking at the linker output, I can see that static libraries are included before binmode.obj, but binmode.obj was included before my own object files.
The real solution should be to persuade all external libraries to include binmode.obj, but this is somewhat non-trivial and might incur significant maintenance overhead in the future.
So I'd like to try to move the binmode.obj to the beginning of the linker command line, but this proved to be surprisingly difficult. I've tried:
target_link_libraries( mylib PRIVATE binmode.obj ) - Got correct position, but got renamed to binmode.obj.lib casuing linker error.
Tried making a static library with binmode.obj as a pre-compiled object, but got an error that the file has a relative path. I have no idea how to make it a full path.
Tried adding it as a linker flag in different ways, even including using toolchain file, but it all ended up with binmode.obj being placed after libraries.
I'm now out of ideas and feel I need help with this. Any suggestions how to fix this?
#fabian's comment made me read the right part of CMake documentation, which made me realize that UNKNOWN library type could be used. Using the following code in CMake I could make binmode.obj appear before all libraries:
add_library( binmode_obj UNKNOWN IMPORTED GLOBAL )
set_target_properties( binmode_obj PROPERTIES IMPORTED_LOCATION binmode.obj )
target_link_libraries( mylib PUBLIC binmode_obj )
This solved my problem of trying out if link binmode.obj before libraries might fix my original problem. It didn't, unfortunately. But that is another problem...
I am using Asio in a Rcpp package, and am therefore using the package AsioHeaders.
I have added BH and AsioHeaders in the "LinkingTo" part of the DESCRIPTION file of my package. I have also added comments
// [[Rcpp::depends(BH)]]
// [[Rcpp::depends(AsioHeaders)]]
in my code. So normally, the linking should be fine when compiling the package.
And it is when I compile it on Linux. But when trying to compile it on Windows, I get linking errors that are solved by linking -lws2_32 and -lwsock32.
I am thus wondering, whether I should edit the Makevars file so that these are linked on Windows but ignored on Linux, or if I have done something wrong using AsioHeaders?
AsioHeaders maintainer here. Quick questions:
Which version of AsioHeaders? It just updated at CRAN. Is this a change from the new version (which would suprise me ...)?
Make sure you are not accidentally using Asio functionality from Boost which will require linking. See the three packages using AsioHeaders.
If your package is truly header-only then LinkingTo: is all you need. R will find the header directories for you. In particular, you do not need link instructions in src/Makevars* because, well, header-only.
Also, you probably meant // forward slashes for your C++ comments above...
I created a simple hierarchial C++ project to help me learn the use of scons as I want to get away from cmake and qmake. I have registered it in a github repository at https://github.com/pleopard777/SConsEx . This project is organized into two primary subdirs; packages contains two libraries and testing contains two apps. The packages dir needs to be built first and when complete the testing dir needs to be built. Under the packages library the core library must be compiled first and the numerics library second. The numerics library depends on the core library. Under the testing dir the core_tests app depends on the core library and the numerics_tests app depends on core and numerics.
I am struggling with what seems to be limited documentation and examples for scons so I am posting this here in search of some guidance. Here are some of the initial problems I am having, any guidance will be greatly appreciated:
1) [Edit/FIXED]
2) In the packages/numerics/ dir the source files depend on the core library. The file numerics_config.h requires the file ../core/core_config.h however when building that core file cannot be found. The following SConstruct lines don't help:
[code]
include = '../../packages'
env = Environment(CPPPATH=include)
[/code]
Again, this is just a start to the project and I am using it to learn scons. Any guidance will be appreciated ... I'm sure I will be asking lots more questions as this project progresses.
Thanks!
P
Fixed in pull request to your repo.
Note you had some c++ issues as well. I've fixed them too.
See:
https://github.com/pleopard777/SConsEx/pull/1
(Please don't delete your repo so others can find the solution as well)
There are current two projects with stack and cabal files each (I use stack to build), one is an exe called test and the other is a library called testlib. I want to use testlib in the test project, what can I do to let stack know testlib is a custom library and how to find it?
-- projects/test/test.yaml
-- projects/testlib/testlib.yaml
I find the answer.
extra-deps solve the problem.
And the test.yaml seems like:
...
extra_deps:
- ../testlib-1.0.0
...
Two points should be noticed:
the path should be relative to the directory containing test.yaml
the name of target lib should be like LIBNAME-VERINFO1.VERINFO2
Any better solution will be welcome. And thanks a lot for the help!
You can use extra-deps or packages according to taste. packages should be used when the extra library (testlib in your example) is part of your development work, and extra-deps when you have a stable release.
The manual has more details.