I have a few custom ticket fields defined in a global config inherited by all our Trac environments. Now I'd like to remove a few of them only for a single environment (but without having to un-inherit the global config which sets a lot more than just the custom fields). The perhaps obvious way
[ticket-custom]
mycustomfield =
did not work. Is there any way?
No, there's no limitation for inheritance in general. So you can't stop a configuration part from propagation, once it's inherited.
You could construct a slightly more fragmented inheritance instead of ditching inheritance to still reach your goal:
global_trac.ini:
all the basic, common stuff
[ticket-custom]
put reduced, common set of custom fields here
global_trac_with_custom_fields.ini:
[inherit]
file = ../global_trac.ini
[ticket-custom]
put full set of custom fields here
your_special_trac_env/conf/trac.ini:
[inherit]
file = ../global_trac.ini
some_other_trac_env/conf/trac.ini:
[inherit]
file = ../global_trac_with_custom_fields.ini
Related
Daniel Pfeifer, in his presentation "Effective CMake",
makes a point, that it is advisable to avoid variable
definitions as much as possible.
Now, how does one get properties into a variety of build
targets. That is, for example
target_include_directories(base_IncludeFlags
INTERFACE
first/dir
second/dir
...)
defines a set of include directories. Instead of defining
the exact same include directories for target_a, target_b,
and target_c, I would like to let those targets inherit
the include directories from 'base_target', with something like
target_link_libraries(target_a PUBLIC base_IncludeFlags)
target_link_libraries(target_b PUBLIC base_IncludeFlags)
target_link_libraries(target_c PUBLIC base_IncludeFlags)
where base_IncludeFlags is shall not be a real physical target,
rather something like an abstract base class or interface.
On the other hand, I do not want to use include_directories
since this affects all targets. Is it better to use foreach?
What is the most elegant way to do this? Shall I make base_target
a library and add dependencies?
What I want is a target that is not actually physically produced, but which propagates some common properties.
Exactly for that purpose CMake has INTERFACE library - container for different properties, which are propagated when this library is linked into another target.
Example:
# Create "container" target
add_library(base_target INTERFACE)
# Add some INTERFACE properties for that target
target_include_directories(base_target INTERFACE
first/dir
second/dir)
# Some 'other_target' (library or executable) may easily consume all common properties:
target_link_libraries(other_target PUBLIC base_target)
# Now 'other_target' has aforementioned include directories too.
# Instead of PUBLIC other linking types (PRIVATE, INTERFACE) may be used.
What is the most elegant way to do this?
Consider that CMake files are often read and edited by people who aren't experts in CMake. Rather than going for elegance, you may consider going for simplicity: keep it simple, stupid.
If you introduce abstractions, hidden implicit behavior of any kind, it will be harder for everybody to maintain the CMake file.
For me, simple in this case would mean copying (duplicating) the entries, if there are just 2-3. If there's more libraries, I'd put the headers in a variable. The "Effective CMake" presentation makes a point to avoid unnecessary, single-use variable definitions. I'd argue that this header list would be a helpful variable, and worth creating.
I've been trying to get Connections to use a customised adapter located at app/extensions/data/source/database/adapter/. I thought extending the Connections class and replacing
protected static $_adapters = 'data.source';
with
protected static $_adapters = 'adapter.extension.data.source';
and changing the connections class used at the top of app/config/bootstrap/connections.php to use app\extensions\data\Connections;
would be enough to get it started. However this just leads to a load of errors where the code is still trying to use the original Connections class.
Is there a simple way to achieve this, or do I have to recreate the entire set of classes from lithium/data in extensions with rewritten class references?
EDIT:
Turns out I was going about this the wrong way. After following Nate Abele's advice, Libraries::path('adapter') showed me where to correctly place the MySql.php file I'm trying to override ;-)
For dealing with how named classes (i.e. services, in the abstract) are located, you want to take a look at the Libraries class, specifically the paths() method, which allows you to define how class paths are looked up.
You can also look at the associated definitions, like locate() and $_paths, to give you an idea of what the default configuration looks like.
Finally, note that the Connections class is 'special' since it defines one path dynamically, based on the supplied configuration: http://li3.me/docs/api/lithium/1.0.x/lithium/data/Connections::_class()
This should help you reconfigure how your classes are organized without extending/overriding anything. Generally you shouldn't need to do that unless you need some drastically different behavior.
Do I really have to use the ClassImp macro to benefit the automatic dictionary and streamer generation in ROOT? Some online tutorials and examples mention it but I noticed that simply adding the ClassDef(MyClass, <ver>) macro to MyClass.h and processing it with rootcint/rootcling already generates most of such code.
I did look at Rtypes.h where these macros are defined but to follow preprocessor macros calling each other is not easy and so, it would be nice if experts could confirm the role of ClassImp. I am specifically interested in recent versions of ROOT >= 5.34
Here is the answer I got on roottalk mailing list confirming that the usage of ClassImp is essentially outdated.
ClassImp is used to register in the TClass the name of the source file
for the class. This was used in particular by THtml (which has now
been deprecated in favor of Doxygen). So unless you code/framework
needs to know the name of the source files, it is no longer necessary
to have ClassImp.
ClassDef is necessary for class inheriting from TObject (or from any
classes that has a ClassDef). In the other cases, it provide
accelerator that makes the I/O slightly faster (and thus is
technically not compulsory in this case). It also assign a version
number to the schema layout which simplifies writing schema evolution
rules (on the other hand, there is other alternative to assign a
version number to the schema layout).
What exactly are you trying to do? The ClassImp and ClassDef macros add members to the class that provide Run-Time Type Information and allow the class to be written to root files. If you are not interested in that, then don't bother with these macros.
I never use them.
The project I'm working on, being rather large, consists of one master module, which I'd like to be the API interface, with a number of sub-modules defined within it. This is being done as follows:
<Library.ts>
module Library { }
<Core/Core.ts>
module Library.Core {}
Often the submodules will span a number of files. The problem I'm having is in such situations, one file cannot use non-exported properties defined within the same sub-module, but in another file.
Is there any way I can use these properties, or failing that, any way I can prevent the entirety of a sub-module's exports being exposed within its parent module?
Is there any way I can use these properties, or failing that, any way I can prevent the entirety of a sub-module's exports being exposed within its parent module?
No. You need to export from module Foo for it to be available to module Foo in another file. The same applies to submodules
I'm using Twitter Bootstrap on a project at the moment, including the LESS files and compiling with some additional LESS code that we've written.
The latest release has meant we need to override some of the Bootstrap LESS variables. One option here was to maintain a modified copy of Bootstrap which we patch on each release.
But I note that it's possible to override a variable defined in an #import LESS file by re-declaring the variable after the import statement.
E.g.:
#import "twitter-bootstrap/bootstrap.less";
// Restore base font size to pre 2.1.1 defaults
#baseFontSize: 13px;
// Add some custom LESS code here
Is this bad practice? Is it an artifact of the way the LESS compiler works, or an intended part of it? I couldn't find much information on this, although I did find the following two references:
Because of a bug in the Less compiler, you can override the “constant” value of a variable by changing it after it is initially declared.
http://rubysource.com/how-to-customize-twitter-bootstrap%E2%80%99s-design-in-a-rails-app
and
Customize the columns and gutters by overriding these three variables (after the grid.less import has been declared).
http://semantic.gs/
The LESS site itself says that variables are 'constants':
http://lesscss.org/
Note that variables in LESS are actually ‘constants’ in that they can only be defined once.
But then I see other sites using this approach.. It's certainly easier than maintaining a vendor branch and seems to work fine with less.js.
Would appreciate any thoughts on whether this is a bad thing to do or not!
Ok! One of the above issues led to a discussion of the intended behaviour, and it turns out that overriding LESS variables is fine.
Your declarations will overwrite each-other in the same scope in CSS; The same is true for LESS.
https://github.com/cloudhead/less.js/issues/297
Like in CSS, overriding within a scope is an intended way to use LESS.
It´s ok!
I usually create a less file with "components" and variables with a default value. Then I import after that a file with same variables but "customers" values, overwritting default ones. In that way i have only to change some values to create a new design for each customer.
It´s ok and very useful.