https://doc.qt.io/archives/qt-4.8/qmake-environment-reference.html#installs
To help in the install process qmake has the concept of a install set.
It looks like a install set have members, i.e. path, files and extra:
documentation.path = /usr/local/program/doc
documentation.files = docs/*
Are there other members?
What members need to be set in order to consider the install set fully described?
Where the create_docs come from in the case below
unix:documentation.extra = create_docs; mv master.doc toc.doc
QMake is documented... not. Whenever you want to know something you go browse source code. In this case, it's in qmake/generators/makefile.cpp, function Makefilegenerator::writeInstalls().
As we can see, it's path, files, base, extra, CONFIG, uninstall and depends. extra (or commands) is an arbitrary line to insert at the top.
What members need to be set in order to consider the install set fully described?
QMake is Makefile generator. Whatever human does it simply outputs some Makefile. Whether it will work or not, that's a human's problem.
Related
Consider the following code:
mt.resolve().getQualifiedSignature();
Here mt is of type MethodDeclaration, and it might come from a MethodCallExpr.
Now in order it to work accurately, I need to set the following:
CombinedTypeSolver combinedTypeSolver = new CombinedTypeSolver();
combinedTypeSolver.add(new ReflectionTypeSolver());
combinedTypeSolver.add(new JavaParserTypeSolver(new File("src/java1/")));
combinedTypeSolver.add(new JavaParserTypeSolver(new File("src/java2/
")));
This is easy, except I have two issues considering my scenario.
1) I can not set the root source directories manually. I need to find them automatically.
2) I can not give path like the above, because I am using jGit to checkout to different commits. So the paths are not fixed and might vary based on the different checkout commits. So the path should be accessed using JGit tree.
Any help would be highly appreciated.
I've seen the question "How does “make” app know default target to build if no target is specified?", which explains that the default target is the first target that doesn't being with a '.'.
How do I get make to tell me what that target is?
Context: I've got a recursive make system, with a variety of included makefiles. If I add a new target to my top level Makefile (or to my common include), that becomes the default target. I want to add .DEFAULT_GOAL: original-default-target, but I don't know what original-default-target is.
Running make -d results in a lot of debug output. If you search this for the first occurrence of 'Updating goal targets', and look at the next target mentioned, this appears to be the default target.
For example:
$ make -d | grep -A2 -m1 'goal targets'
Updating goal targets....
Considering target file 'all'.
File 'all' does not exist.
This implies that, for this Makefile at least, the current default target is all. This can then be enforced by adding .DEFAULT_GOAL: all to the top-level Makefile.
How can I stop Qt from renaming my DLL to MyDLLName{MAJOR_VERSION_NUM}.dll?
This only happens when I set the VERSION in my project file, but I also want to set the version. For example, if I have:
VERSION = 1.2.3.4
And my library is named MyDll, it will create my DLL in the debug folder as MyDLL1.dll. If I take the version number away, it keeps the name as I want it (MyDLL.dll).
Thanks.
Use this:
CONFIG += skip_target_version_ext
See this answer (on SO) for why it is there: Why library name gets an additional 0 in its name?
You can "not-set" the version to remove it from the generated name, but are you sure you want to do that? (It's there to avoid DLL Hell.)
The "proper-answer" is that the LIB template is adding the version number.
Also, note:
VERSION is used to define VER_MAJ and VER_MIN
msvc_nmake generator adds /VERSION:major.minor to link flags if !empty
msvc_vcproj generate adds /VERSION:major.minor to link flags and MSVCPROJ_VERSION if !empty
You can explicitly set those yourself, or "unset" any of them.
You can explicitly remove the version number from the target name with the TARGET_EXT variable, for example, see: http://qt-project.org/faq/answer/how_can_i_add_version_information_to_my_application
If you want to create your own plugin to decide how to generate the target name (without the version number), you can make your own plugin as described in this answer (on SO): How to avoid having version numbers in .so file name
I am trying to use filters to select specific tables to replicate.
I tried running this with the installer
./tools/tungsten-installer --master-slave -a \
...
--svc-extractor-filters=replicate \
--property=replicator.filter.replicate.do=test,*.foo"
and got this exception in trepctl status after the master had not installed properly:
Plugin class name property is missing or null: key=replicator.filter.replicate
which file is this properties file? How do I find it? Moreover, in specifying the settings for the filter, how do I know what exactly to put?
I discovered that I am supposed to Modify the configuration template file prior to configuration according to Issue 219 but what changes am I supposed to make in tungsten-replicator-2.0.5-diff that will later on be patched to the extraction?
Issue 254 suggests that If you want to apply a filter out of the box, you can use these options with tungsten-installer:
-a --property=replicator.filter.Replicate.ignoreFilter=schema_x.tablex,schema_x,tabley,schema_y,tablez
--svc-thl-filter=Replicate
However when I try using this for --property=replicator.filter.replicate.do,
but the problem is still the same:
pendingExceptionMessage: Plugin class name property is missing or null: key=replicator.filter.replicate
Your assistance will be greatly appreciated.
Rumbi
Update:
Hi
I had a look at this file: /root/tungsten/tungsten-replicator/samples/
conf/filters/default/tableignore.tpl .Acoording to this sample, a
static-SERVICE_NAME.properties file is supposed to have something like
this configured, please confirm if this is the correct syntax:
replicator.filter.tabledo=com.continuent.tungsten.replicator.filter.JavaScr iptFilter
replicator.filter.tabledo.script=${replicator.home.dir}/samples/
scripts/javascript-advanced/tabledo.js
replicator.filter.tabledo.tables=foo(database).bar(table)
replicator.stage.thl-to-dbms.filters=tabledo
However, I did not find tabledo.js (or something similar) in the
directory where tableignore.js exists. Could I please have the
location of this file. If there is an alternative way of specifiying
--property=replicator.filter.replicate.do=test without the use of
this .js file, your suggestions are most welcome.
Download the latest version of tungsten replicator. The missing tpl file was added about a month ago. After installation, the filtered tables should be added to static-service.properties under the section FILTERS.
Locate your replicator configuration file in static-YOUR_SERVICE_NAME.properties, e.g.
/opt/continuent/tungsten/tungsten-replicator/conf/static-mysql2vertica.properties
Make sure the individual dbms properties are set, in particular the setting replicator.applier.dbms:
# Batch applier basic configuration information.
replicator.applier.dbms=com.continuent.tungsten.replicator.applier.batch.SimpleBatchApplier
replicator.applier.dbms.url=jdbc:mysql:thin://${replicator.global.db.host}:${replicator.global.db.port}/tungsten_${service.name}?createDB=true
replicator.applier.dbms.driver=org.drizzle.jdbc.DrizzleDriver
replicator.applier.dbms.user=${replicator.global.db.user}
replicator.applier.dbms.password=${replicator.global.db.password}
replicator.applier.dbms.startupScript=${replicator.home.dir}/samples/scripts/batch/mysql-connect.sql
# Timezone and character set.
replicator.applier.dbms.timezone=GMT+0:00
replicator.applier.dbms.charset=UTF-8
# Parameters for loading and merging via stage tables.
replicator.applier.dbms.stageTablePrefix=stage_xxx_
replicator.applier.dbms.stageDirectory=/tmp/staging
replicator.applier.dbms.stageLoadScript=${replicator.home.dir}/samples/scripts/batch/mysql-load.sql
replicator.applier.dbms.stageMergeScript=${replicator.home.dir}/samples/scripts/batch/mysql-merge.sql
replicator.applier.dbms.cleanUpFiles=false
Depending on the database you are replicating to you may have to omit/modify some of the lines.
For more information see:
https://code.google.com/p/tungsten-replicator/wiki/Replicator_Batch_Loading
I don't know if this problem is still open or not.
I am using this version 2.0.6-xxx and installing the service using the parameters works for me.
I would like to point it out, that as the parameter says "--svc-extractor-filters" defines an extractor filter. Meaning that the parameters will guide the extraction of data in the master server.
If you intend to use it on the slave service, you should use the "--svc-applier-filters".
The parameters
--svc-extractor-filters=replicate \
--property=replicator.filter.replicate.do=test,*.foo"
supposed to create the following in the properties file:
This is the filter set up.
replicator.filter.replicate=com.continuent.tungsten.replicator.filter.ReplicateFilter
replicator.filter.replicate.ignore=
replicator.filter.replicate.do=test,*.foo
And you should also be able to find the
replicator.stage.binlog-to-q.filters=replicate
parameter set.
If you intend to use this filter in the slave, please find the line with:
replicator.stage.q-to-dbms.filters=mysqlsessions,pkey,bidiSlave
and change it as
replicator.stage.q-to-dbms.filters=mysqlsessions,pkey,bidiSlave,replicate
Hope this brief description did help to you!
Is there any way to add a post build command to an omakefile? I want it to automatically run unit tests everytime a build is successful, but am not sure of the best way to do this.
You can add commands to the .DEFAULT target. For example:
FILES[] =
...
CXXProgram(unittests, $(FILES))
.DEFAULT: unittests$(EXE)
./unittests$(EXE)
When invoked without any particular target, Omake will build all default targets, then run associated commands.
I think you can use .BUILD_SUCCESS and .BUILD_FAILURE targets for that purpose.
See details here.