I'm working in a large sphinx project with long compile time.
I want to find a way to compile my file(s) of interest without dealing with the entire project.
One way to reduce this is to create an index_small.rst and change the makefile to use that rst instead of the standard index.rst.
One problem with this is that I get warnings for all the rst files I haven't included in the toc tree.
Use the exclude_patterns and :orphan: directives on your index_small.rst:
Use exclude_patterns to explicitly exclude documents or directories from building completely. Use the “orphan” metadata to let a document be built, but notify Sphinx that it is not reachable via a toctree.
Related
I have quite a large multi-module multi-language maven project (~100 modules in total), which I want to analyze using SonarQube and since the scanner doesn't automatically discover all files in all languages (i.e. not for Groovy and Kotlin), I have to tell it where to look for the files.
Most module contain the typical combination of a src/main/ and a src/test/ directory but not necessarily both, which makes it impossible to simply declare <sonar.sources>pom.xml,src/main/</sonar.sources> and <sonar.tests>src/test/</sonar.tests> as properties in the top level pom, since the missing directory causes maven to abort with an error.
According to https://stackoverflow.com/a/37545474 one possible solution to this problem is to
set ...
sonar.sources to be .
sonar.inclusions to be src/main/**
=> this will include all the known files that SQ finds in your modules in the src/main folder if it exists
and using just
<sonar.sources>.</sonar.sources>
<sonar.tests>.</sonar.tests>
<sonar.inclusions>pom.xml,src/main/**</sonar.inclusions>
<sonar.test.inclusions>src/test/**</sonar.test.inclusions>
in the top level pom indeed works as expected (all files, that are supposed to be analyzed, are found and no errors are reported because of missing directories) but it also causes the following warning, which shows up in SonarQube as well:
[WARNING] Specifying module-relative paths at project level in the property 'sonar.inclusions' is deprecated. To continue matching files like 'frontend/pom.xml', update this property so that patterns refer to project-relative paths.
All paths I tried so far either cause less files to be analyzed in total or result in an error because individual files would be indexed multiple times, due to non disjoint sets produced by the inclusion patters. Thus the question ...
How do I have to use the *.inclusions properties to get rid of the warning, while still analyzing all files in all submodules?
gresens,
I have the same problem using Jenkins pipeline. I resolved including the "projectBaseDir" parameter, like this:
<properties>
<sonar.projectBaseDir>.</sonar.projectBaseDir>
</properties>
Reference: https://community.sonarsource.com/t/relationship-between-projectbasedir-sources-and-exclusions/12785
Is it possible to have CMake-QT generate individual .obj files during AUTOMOC thus allowing for Whole Program Optimization during link time?
If yes - how?
TLDR - Pseudologic:
CMAKE_AUTOMOC ON => [mocs_compilation.obj != (moc_a.obj moc_b.obj)] => linker(one_instead_of_many.obj)? dependency missing : no dependency missing
Situation
When I set CMAKE_AUTOMOC ON in a Project, a file named mocs_compilation.cpp is created in the <project_name>_autogen folder which includes the AUTOMOCed files and thus creates one object instead of several individual files.
Why I think it is important?
Using Link Time Code Generation/Whole Program Optimization in Visual Studio 2015 our build (with custom moc-generation steps and individual .boj files) works without problems - possibly getting rid of unnecessary .obj files thus even eliminating a dependency to an extra LIB/DLL.
PS: By the way I really think there should be a cmake-qt tag if anyone cares to create one.
Seems it is a general issue with CMake:
https://gitlab.kitware.com/cmake/cmake/issues/17277
I've done the various steps to adapt CMU Sphinx using some recorded WAV files. Now where to the resulting files go?
I want to let each user on the system adapt CMU Sphinx to his own voice, so I don't want to store the files in /usr/local.
Is there a default directory or do I just have to specify them and their locations every time I run pocketSphinx?
Depending on the type of adaption you use, the resulting files can be either a transformation matrix which you specify with -mllr or a completely new model which is saved where you pointed out to. Adapted model has the same structure as the default one, so yes, you specify them and their locations every time your run the application. See the official tutorial for more information.
Can you include expressions in the "Output Files" section of a build rule in Xcode? Eg:
$(DERIVED_FILE_DIR)$(echo "/dynamic/dir")/$(INPUT_FILE_BASE).m
Specifically, when translating Java files with j2objc, the resulting files are saved in subfolders, based on the java packages (eg. $(DERIVED_FILE_DIR)/com/google/Class.[hm]). This is without using --no-package-directories, which I can't use because of duplicate file names in different packages.
The issue is in Output Files, because Xcode doesn't know how to search for the output file at the correct location. The default location is $(DERIVED_FILE_DIR)/$(INPUT_FILE_BASE).m, but I need to perform a string substitution to insert the correct path. However any expression added as $(expression) gets ignored, as it was never there.
I also tried to export a variable from the custom script and use it in Output Files, but that doesn't work either because the Output Files are transformed into SCRIPT_OUTPUT_FILE_X before the custom script is ran.
Unfortunately, Xcode's build support is pretty primitive (compared to say, make, which is third-odd years older :-). One option to try is splitting the Java source, so that the two classes with the same names are in different sub-projects. If you then use different prefixes for each sub-project, the names will be disambiguated.
A more fragile, but maybe simpler approach is to define a separate rule for the one of the two classes, so that it can have a unique prefix assigned. Then add an early build phase to translate it before any other Java classes, so the rules don't overlap.
For me, the second alternative does work (Xcode 7.3.x) - to a point.
My rule is not for Java, but rather for Google Protobuf, and I tried to maintain the same hierarchy (like your Java package hierarchy) in the generated code as in the source .proto files. Indeed files (.pb.cc and .pb.h) were created as expected, with their hierarchies, inside the Build/Intermediates/myProject.build/Debug/DerivedSources directory.
However, Xcode usually knows to continue and compile the generated output into the current target - but that breaks as it only looks for files in the actual ${DERIVED_FILE} - not within sub-directories underneath.
Could you please explain better "Output Files are transformed into SCRIPT_OUTPUT_FILE_X" ? I do not understand.
Can I change the root of the treeview with a custom link instead of index.html?
Or at least add html before the treeview on the side-nav?
I think the answer is not with the vanilla Doxygen.
However, you may be able to get someway by using the '#page' documentation, which Doxygen will include before the API tree.
Doxygen also recognises '.dox' files as just containing Doxygen comment blocks - while not required for #page, these are useful where the supporting documentation is not linked to any particular source file. I've used these in the past to build the full SDK document, with background, examples, etc.
A variant is the '#mainpage', which comes first - otherwise #page entries are unordered. In the past I have modified Doxygen to order #pages by their internal name (as opposed to their title).