I have multiple projects that I want to share a similar .clang-format style, but I also want to be able to make minor tweaks between each project so they can be slightly different from one another if needed. Currently each project just has the same .clang-format file copied and pasted into its own repository, but it feels wrong because all of the style options are just duplicated from project to project and if I need to change one option I need to go across all projects and manually change it in all of them.
I would like to create my own style that can be used with the "BasedOnStyle" option (See here for more info). That way I can specify that I want all of these projects to be based on the same custom style that would be kept in a shared location, and then I could easily override any project specific options on a per-project basis.
As far as I can tell, there doesn't appear to be any way to create your own style and save it so other projects can be based on the same style. I feel like this is something a lot of users would need (for example if a company wanted to define their own master style that all projects should follow there doesn't appear to be a good way to do it).
Has anyone else run into this problem and found a good solution?
I reached out to the llvm-dev email list and got a response. A feature request is in the works to do something similar to what I want, but not exactly the same. Either way, this should be suitable for my needs when it becomes available.
https://reviews.llvm.org/D93844
Related
Considering all freedom that yocto gives to the developer, I have a question.
I would like to make this my_file.inc available only for recipes in one particular meta-layer. I know, that, for instance, using INHERIT keyword inside the local.conf will make my_class.bbclass file available globally for each recipe.
Is it a good practice to add this:
require my_file.inc
inside layer.conf? Or should I change my_file.inc to the my_file.bbclass, and, add INHERIT = "my_file.bbclass" to the layer.conf?
Any other possibilities?
Even if it seems to work, neither of your approaches is technically completely correct. The key point is that all .conf files are parsed first and everything they contain is globally visible throughout the whole build process. So if you add something through the layer.conf file, itis not being pulled in through an unexpected place, it also is not being limited that layer only and might therefore cause breakage at other places.
While I do not have a really good and clean solution, maybe the following can help you:
You can make your custom recipes react on certain keywords in DISTRO_FEATURES or MACHINE_FEATURES. Then you can create a two-staged approach:
Add the desired keyword in local.conf (or your MACHINE, or DISTRO, or whatever configuration)
Make the recipes react to it. If you need the mechanism in several places, then it might be useful to pour it into a .bbclass that your layer brings along and that you pull in for the respective recipes.
This way the effect is properly contained.
Maybe part 5.1.3.2 from the Yocto Project answers your question:
Avoid duplicating include files. Use append files (.bbappend) for each recipe that uses an include file. Or, if you are introducing a new recipe that requires the included file, use the path relative to the original layer directory to refer to the file. For example, use require recipes-core/package/file.inc instead of require file.inc. If you're finding you have to overlay the include file, it could indicate a deficiency in the include file in the layer to which it originally belongs. If this is the case, you should try to address that deficiency instead of overlaying the include file. For example, you could address this by getting the maintainer of the include file to add a variable or variables to make it easy to override the parts needing to be overridden.
So to avoid duplicate inclusion later, it would be better not to include your .inc file(s) this way.
Structural search in IntelliJ IDEA is not only powerful, but also not trivial at all to get right. Now when I have created a working template of my own, I might want to use it in multiple projects.
I do not see a way to save globally. Is there anything I can do short of copying the relevant bits from one workspace.xml to another?
Unfortunatelly, it's not supported at the moment, please follow this feature request for updates.
I have few separate apps that have absolute same logic and functions but have different icons and some design elements. The problem is that when some changes to logic and functions are made - I need to manually add this functionality to all apps and after this - I need to resubmit each app.
Maybe there is some way to separate all logic so I need to change it only in one place, and all my apps would get it?
In my opinion the neatest solution is to have one codebase with multiple targets. Yes you still have to resubmit each app when you change some code, but you would have to do that anyway would you not?
You can pick one of your apps to convert to your 'main' codebase.
E.g. Pick app one and duplicate the target multiple times:
You will want to change your scheme names after doing this:
You can set the bundle identifier and deployment info separately for each app just as you did before, and icon sets:
To differentiate between your apps in code you can use compiler flags (Target -> Build settings - Other swift flags) :
You can then do something like this in your code:
#if APP_ONE
...
#else
...
#endif
One solution (though not necessarily the best) is to have a single code base. I.e. you have only one physical copy of each of your classes. All your code files are located in a folder of one of the projects and the other projects use those files as well. It's just a matter of setting paths.
In this structure when you change or add some code in one of the projects (and doesn't really matter which one), all the projects are updated.
The image catalogs are different for each project.
The disadvantages of this approach are that you still need to build and submit each app separately and when adding a new class you need manually to add it to all the projects. Otherwise they won't compile.
The advantages are that when building an app, you build only one app and not all together (less time). It's also easy to manage changes to a specific app - you can just add some extension with additional functionality to only one project - the rest won't need it.
I am working with a big project on my IDEA with many modules. I would like to compare files and directories in the project view. Scrolling each time just to select the files for comparison is tedious. I am not using scroll from source so what I wanted to have is two views of the project, each one is scrolled to different files.
Is there a way to achieve that? Or any other alternative?
The closest you can get is the favourites view where you can drop individual files into a list and then compare them without having to scroll around the project view. Unfortunately that is only any use if you are comparing the same sets of files each time.
Unfortunately there is no out of the box way to do that, IDEA can run multiple instances, each with a different project, but switching is kind of painful.
One workaround is to import multiple maven projects as a modules of one project as described in this question.
There is an issue for that feature in the JetBrains issue tracker, it is interesting to read the conversation history there. Currently it seems JetBrains do not plan to implement this feature anywhere in the future.
...it makes no sense in IDEA. Unlike other platform-based IDEs, IDEA
supports multi-module projects, and all the contents displayed in a
single frame are modules of a single project. Introducing an extra
level of hierarchy above that would be unnecessary and extremely
confusing.
...
We don't have any plans to provide any other solution for this. The
1:1 correspondence between projects and frames is essential to the
internal design of IntelliJ IDEA: by definition, a project is the set
of code opened in a single frame. There is no way to change this
without rewriting the whole IDE, which we don't plan to do.
There was such view in intelliJ called Commander. Since last versions it's not shipped together with intelliJ, but you can install it as a plugin.
I think it will be helpful for your case.
I am relatively new to Grails and I am little disappointed with the way _form.gsp removed with field plugin in Grails 3. _form.gsp seemed to be good time saving option when we need to customize views with Bootsrap or materialize.
Now with grails 3, install-templates does not create _form.gsp. As per this documentation, we can achieve customization by creating _wrapper.gsp, _widget.gsp etc under view/_fields/default directory. But I am not able to find the example of such custom GSPs.
Also, let's say if I customize all the four GSPs (_wrapper.gsp, _widget.gsp, _displayWrapper.gsp, _displayWidget.gsp) will it generate actual code when we run generate-view command? I mean will it replace, f:all, f:table etc tag with actual code? If not then there is quite amount of work to do I guess. Because after we are confident about our domain class and tested all CRUD operation, we run generate-view command for creating all the domain specific GSPs. Then in most cases, we need to do some changes according to our requirement, like re-ordering the fields, hiding some of the fields
So in conclusion I have two goals:
Customizing default templates and start developing.
When I run generate-view, I do not want f:all, f:table etc abstract tags. I need actual fields in place so that I can customize generated views of domain.
If any one has achieved this, then please share the solution.
Grails 3 comes with the fields plugin by default. The templates used in Grails 2.x have been replaced in full. So, your goal 2. will be hard to achieve with Grails 3 it seems.
However, here is a helpful blog which explains how you can adjust some of the fields templates by replacing them in your project: http://blog.anorakgirl.co.uk/2016/01/what-the-f-is-ftable/
Similar to the description provided, you can place a modified _list.gsp template in folder in
/grails-app/views/templates/_fields/
Hope it helps.