In Gevent 1.1, there are two backends, cython and cffi. What I confuse is _corecffi_build.py.
In line 331,
ffi.set_source('gevent._corecffi', _source, include_dirs=include_dirs)
I do not know why ffi.set_source does not specify sources to include related c files. And _source only contains some declarations.
How the c source files are included?
The "c source files" are included in a libev-specific way. In the _source string we #define LIBEV_EMBED before we #include "libev.h". Setting that macro causes libev.h itself to #include "ev.c", which is all the source libev needs.
Related
Using the defgroup Doxygen keyword in a Doxygen comment block, it is possible to define a "module". Then, using the ingroup Doxygen keyword in any other Doxygen comment block, even in other source files, it is possible to add cpp classes and enums to the defined module.
Then, running doxygen doxyfile, the documentation is generated, and it has a nice modules tab, where all the defined modules are listed, one per line.
I have a C++ project and I would like to also have this module list that Doxygen generates in Sphinx. I activated the autodoc, breathe and exhale sphinx extensions.
Running make html runs Doxygen and generates the sphinx documentation, but the list of modules generated by Doxygen is missing in sphinx. In conf.py I have
# Setup the `exhale` extension
exhale_args = {
# These arguments are required.
"containmentFolder": "./api",
"rootFileName": "library_root.rst",
"rootFileTitle": "Library API",
the api/library_root.html generated by sphinx/exhale has a nice expandable list of all namespaces, each containing all its classes and enums. It also has another nice expandable list of all directories in the project, each with all its files.
So my question is this - how can I get sphinx to also generate the list of modules which doxygen has no trouble generating? It doesn't matter if in the library_root.html or another HTML file.
I found that if I use the name Doxygen keyword, like this: name module1 in a Doxygen comment (with leading backslash or at symbol) breathe seems to recognize it, whereas it seems to not recognize and ignore defgroup/ingroup.
So, in an rst file, I can then manually say
.. doxygengroup:: module1
:outline:
.. doxygengroup:: module2
:outline:
.. doxygengroup:: module3
:outline:
to get the list of modules, (they are labeled group not module) but I want this to be autogenerated, like in Doxygen, where I just define the modules in Doxygen comments in the source, and then they all appear in the modules tab in the Doxygen output without having to do anything else. I would prefer that they are labeled module, but I can live with group as long as it works.
I also tried adding in index.rst
.. automodule:: My Project
:members:
before .. toctree:: but that has no effect, it probably only works in Python.
I use Linux and have Sphinx 1.6.7 on one machine and 1.8.5 on another, Python 2.7
I would like to use wxWidgets 3.0.2 library in my project. However I am unable to run even the hello world program. I have downloaded the headers and the appropriate binaries (TDM GCC x64 4.8.1). I've extracted them without any changes. So there are include and libs folders present in my wxWidgets folder. I am using TDM-GCC 5.1 which is setup properly.
When I create a simple console application and only include the main file
#include "C:\wxWidgets\include\wx\wx.h"
I get an error
C:\wxWidgets\include\wx\wx.h|14|fatal error: wx/defs.h: No such file or directory|
Which is quite reasonable, as defs.h is in the same folder as wx.h and there is no wx folder inside. Do I need to rearrange the file structure?
Is the compiler problem here (5.1 used instead of 4.8.1)?
For three days I am running trough different tutorials, and all the time I get this or similar errors. How to set it up properly?
The whole code is just:
#include <iostream>
using namespace std;
#include "C:\wxWidgets\include\wx\wx.h"
int main()
{
cout << "hello" << endl;
return 0;
}
You should never include wxWidgets (or any other library) header files using full paths. Instead you should have just
#include <wx/wx.h>
in your code and set up your compiler headers search path to include c:\wxWidgets\include directory. Notice that you will also need to add c:\wxWidgets\lib\gcc481_lib\mswu or similar to the includes path, depending on the exactl configuration you're using (e.g. it could be gcc481_dll if you're using the DLL build).
I'm working on text editor (almost IDE) and i'm using llvm/clang behind the scenes (tokenizing, diagnostics). Almost every file that is edited includes main header file which includes some headers too which include some other headers (tree of included files):
UserFile.h
L----MainHeader.h
L----string.h
L----device.h
| L----(in some conditions)---concreteDevice.h
L----math.h
|
...
The main idea is skip reparsing headers that remain the same during editing 'UserFile.cpp' in clang_parseTranslationUnit and clang_reparseTranslationUnit invocations.
I've read about Clang's chained precompiled headers or even modules which seems to be what i need.
I've generated PCH for MainHeader.h like clang++ -x c++-header MainHeader.h -emit-pch -o MainHeader.h.pch and used it like clang++ -include-pch MainHeader.h.pch .... I'm not sure if it's PCH for the whole headers tree (chained) or for that file only (most likely).
Do i need chained precompiled headers since there is CXTranslationUnit_PrecompiledPreamble clang option?
How can i generate chained precompiled headers?
Headers tree is pretty complicated because of multiple #ifdef SOME_CONDITION .. #include <SomeHeader.h> #endif and it's pretty difficult to understand the whole tree and precompile PCH for each header file manually (but i do know arguments -DSOME_CONDITION to pass which affect inclusions tree).
Trying to figure out how to use BGL from within Objective-C++. Something is amiss. Steps to repro:
New Cocoa Application project.
Rename MyAppDelegate.m to MyAppDelegate.mm
Add #include <boost/shared_ptr.hpp> to MyAppDelegate.mm (works fine, assuming you have your header search paths set right.)
Add #include <boost/graph/adjacency_list.hpp> to MyAppDelegate.mm
Something transitively included by boost/graph/adjacency_list.hpp is colliding with some old Carbon headers that are being transitively imported by the Cocoa headers. Here is the output I see (the first error's worth anyway):
In file included from /Users/me/Documents/Projects/BoostTest/BoostTest/MyAppDelegate.mm:10:
In file included from /Users/me/Documents/Projects/BoostTest/boost/graph/adjacency_list.hpp:33:
In file included from /Users/me/Documents/Projects/BoostTest/boost/graph/graph_traits.hpp:27:
In file included from /Users/me/Documents/Projects/BoostTest/boost/pending/property.hpp:13:
In file included from /Users/me/Documents/Projects/BoostTest/boost/type_traits.hpp:35:
In file included from /Users/me/Documents/Projects/BoostTest/boost/type_traits/has_operator.hpp:12:
In file included from /Users/me/Documents/Projects/BoostTest/boost/type_traits/has_bit_and.hpp:43:
/Users/me/Documents/Projects/BoostTest/boost/type_traits/detail/has_binary_operator.hpp:154:42: error: expected member name or ';' after declaration specifiers
static ::boost::type_traits::yes_type check(has_operator); // this version is preferred when operator exists
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^
In file included from /Users/me/Documents/Projects/BoostTest/BoostTest/MyAppDelegate.mm:9:
In file included from /Users/me/Documents/Projects/BoostTest/BoostTest/MyAppDelegate.h:9:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:12:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:76:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSURLError.h:12:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/CoreServices.framework/Headers/CoreServices.h:23:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/AE.framework/Headers/AE.h:20:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/CarbonCore.h:115:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/Debugging.h:212:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/AssertMacros.h:1291:28: note: expanded from macro 'check'
#define check(assertion) __Check(assertion)
^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/AssertMacros.h:280:5: note: expanded from macro '__Check'
do \
^
If I remove the #import <Cocoa/Cocoa.h> from the project's prefix header, and then #include <boost/graph/adjacency_list.hpp> before including <Cocoa/Cocoa.h> in MyAppDelegate.mm things will compile, but this is sub-optimal/undesirable.
Is there something simple I can do (ideally in the prefix header so I don't have to do this everywhere) to make the Cocoa headers and the BGL headers co-exist peacefully?
Should have googled for epsilon more time before asking. Just after posting this I found this page which explains that adding the following line prior to including the Cocoa headers will do the trick:
#define __ASSERT_MACROS_DEFINE_VERSIONS_WITHOUT_UNDERSCORES 0
I had tried doing that in my individual MyAppDelegate.mm file, and it didn't work, but that was because of the prefix header. Adding it to the project's prefix header prior to its inclusion of Cocoa/Cocoa.h did the trick.
I'm using CMake to build a shared library, however for the Windows DLL I need the versioning information, like:
FileDescription
FileVersion
InternalName
LegalCopyright
OriginalFilename
ProductName
ProductVersion
So far, all I have are the VERSION and SOVERSION properties, but these don't seem to correlate to the FileVersion information I was expecting.
set(LIC_TARGET MySharedLib)
add_library(${LIC_TARGET} SHARED ${SOURCES} )
SET_TARGET_PROPERTIES(${LIC_TARGET}
PROPERTIES
VERSION ${MY_PRODUCT_NUMBER}.${MY_PRODUCT_VERSION}.${MY_BUILD_NUMBER}
SOVERSION ${MY_PRODUCT_NUMBER})
I've found manual methods (see example at the bottom) but would prefer to contain this within CMake.
Help?
You could use your CMake variable values in conjunction with a version.rc.in file and the configure_file command.
// version.rc.in
#define VER_FILEVERSION #MY_PRODUCT_NUMBER#,#MY_PRODUCT_VERSION#,#MY_BUILD_NUMBER#,0
#define VER_FILEVERSION_STR "#MY_PRODUCT_NUMBER#.#MY_PRODUCT_VERSION#.#MY_BUILD_NUMBER#.0\0"
#define VER_PRODUCTVERSION #MY_PRODUCT_NUMBER#,#MY_PRODUCT_VERSION#,#MY_BUILD_NUMBER#,0
#define VER_PRODUCTVERSION_STR "#MY_PRODUCT_NUMBER#.#MY_PRODUCT_VERSION#.#MY_BUILD_NUMBER#\0"
//
// ...along with the rest of the file from your "manual methods" reference
And then, in your CMakeLists.txt file:
# CMakeLists.txt
set(MY_PRODUCT_NUMBER 3)
set(MY_PRODUCT_VERSION 5)
set(MY_BUILD_NUMBER 49)
configure_file(
${CMAKE_CURRENT_SOURCE_DIR}/version.rc.in
${CMAKE_CURRENT_BINARY_DIR}/version.rc
#ONLY)
set(LIC_TARGET MySharedLib)
add_library(${LIC_TARGET} SHARED ${SOURCES}
${CMAKE_CURRENT_BINARY_DIR}/version.rc)
# Alternatively you could simply include version.rc in another rc file
# if there already is one in one of the files in ${SOURCES}
I'm had same problem and have automated version generation for my projects.
You need three files from github:
generate_product_version.cmake
VersionInfo.in
VersionResource.rc
Put it in cmake subdirectory of your project and make sure to include it to CMAKE_MODULE_PATH like:
set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} ${CMAKE_SOURCE_DIR}/cmake)
Then before add_executable() or add_library(SHARED) your target, use:
include(generate_product_version)
generate_product_version(
VersionFilesOutputVariable
NAME "My Great Project"
ICON ${PATH_TO_APPLICATION_ICON}
VERSION_MAJOR 1
VERSION_MINOR 3
VERSION_PATCH ${BUILD_COUNTER}
VERSION_REVISION ${BUILD_REVISION}
)
Full list of supported resource strings see in generate_product_version.cmake.
VersionInfo.h and VersionResource.rc will be generated to cmake binaries folder. Variable VersionFilesOutputVariable will hold paths to these files. Just add this list to your target:
add_executable(MyGreatProject ${your-target-sources} ${VersionFilesOutputVariable})
UPDATE: Corrected generate_product_version script parameters from VERSION_PATH
to VERSION_PATCH.
There is an even easier way than the accepted answer. It does not involve transforming an input resource.rc.in. Simply create a generic version.rc file as described here and then from your CMakeLists.txt do this:
#CMakeLists.txt
add_definitions(-DVER_COMPANYNAME_STR="MyCompany")
add_definitions(-DVER_FILEVERSION_STR="1,1,0.0")
# ...
# add all the other defines here
set(LIC_TARGET MySharedLib)
add_library(${LIC_TARGET} SHARED ${SOURCES} version.rc)
This has the added benefit that the defines are accessible from your source code as well, so you have programmatic access to your version.