Assume we have a project with the following structure:
root/
.hhconfig
├── directory1
├── directory2
├── directory3
.........................
├── directory10
Is there a way to have a single .hhconfig file, and exclude onlydirectory8 from the typechecking? I think it would be really painful to put separate .hhconfig files, inside every directory or declare as UNSAFE all the files on directory8 in order to be excluded from the typechecking.
This is not supported. A Hack project is designed to be checked as a single project, with full analysis going across all of the different parts of it. If it doesn't typecheck as a whole, then the behavior of HHVM on it is undefined.
You should really, really carefully consider why you're trying to exclude part of the project from typechecking. You really shouldn't have a large body of type-incorrect code. You may want to consider leaving that code back in PHP -- it sounds unlikely to be valid Hack code, or to become such soon. Hiding these type errors is crippling the typechecker's ability to help you find problems in the other code in your project.
You may also be able to use a different mode, decl mode which will exclude all the code in a file from having function bodies typechecked (but which will still make the definitions available to other files). But again, this is just shoving a problem under the rug. Ideally you'd fix all of the type errors instead!
Also, definitely don't put separate .hhconfig files in each directory -- they'll be checked as separate subprojects and none of the analysis will look across the borders of the subdirectories!
Related
Sonarqube is displaying errors for empty css/scss files in the Angular application. What are the effects of having empty scss files? Do they cause issues with performance, side bugs/errors, future problems, what are the compound negative issues? These are generally leftover when we do ng generate component
Sonarqube flag: Remove this empty stylesheet
Article below states to ignore it, compiler will take care of it, however more interested in the effects of leaving empty files, if there are any.
Empty style (.css/.scss) files
Company would have to go through 1000+ empty scss files in large application, interested to know if its worth the time.
As far as I can tell from looking into this, the best answer is to just leave it. The compiler will indeed handle the empty files appropriately.
SonarQube is just picking it up as code smell, empty files should probably be removed to keep a project in its least complex state possible. In the example you gave with a company going through that many files it is a complete waste of time.
I come from the future and I face the same problem, our solution was to delete the files that were already empty and generate the new components with the --inline-style option, this way no css/scss files are created by default when create the components.
Somewhat new to salt here. I set up salt and managed to get everything working rather nicely. After the setup, I decided to try make small state files and run those from another state file. The main reason being ease of troubleshooting/changing a small file vs. troubleshooting a huge state file. Unfortunately, outside of the top file, I haven't been successful in getting a state to be called from another state.
For example, let's say I have foo.sls and bar.sls, and bar.sls is a state that installs packages properly. I have tried the following.
#foo.sls
packages:
state.apply:
- source: salt://packages/bar.sls
Also
#foo.sls
packages/bar.sls:
state.apply
And also
#foo.sls
state.apply:
- source: salt://packages/bar.sls
And few others that I'm not remembering right now.
Most times I've tried though, I get an error stating that state.apply is not available, leading me to believe this is either not possible, or I'm going about it wrong.
Can this be done? If so, how? If not, maybe I'll file a feature request for this, as it seems like it could be useful.
background
It sounds like your issue may stem from mixing state modules and execution modules when you are writing your states.
Brief recap, "states" are the declarative files you write (foo.sls, bar.sls), "state modules" are the directives you list inside those states (e.g. pkg.installed), and "execution modules" provide the commands that salt actually knows how to run (state.apply, test.ping, etc.).
state.apply is simply the execution module that knows how to interpret states. It may help to note that the fully qualified name of state.apply from the docs (or if you browse the salt source tree) is actually salt.modules.state.apply, whereas pkg.installed is salt.states.pkg.installed. A module in the modules namespace generally cannot be accessed from states namespace and vice versa, though there are exceptions. Knowing the full namespace is also a necessary distinction when an execution module and a state modules share a virtual name, e.g. test exists as both salt.modules.test and salt.states.test.
solution
If I understand correctly, you probably want to include your state files within each other.
For example, say you have the following folder structure:
$ tree srv
srv
└── salt
├── foo.sls
└── packages
└── bar.sls
and bar.sls has the following contents
# bar.sls
packages_bar_install_fun:
pkg.installed:
- pkgs:
- cowsay
- fortune
- sl
To include bar.sls into foo.sls you just need to reference it using dot notation, depending on your folder structure
# foo.sls
include:
- packages.bar
foo_another_example_state:
test.show_notification:
- text: |
foo.sls can have other states inside of it,
though you may need to use `require` if you want
them interspersed between multiple includes
Now you can either just include - foo in your top.sls, or run salt '<tgt>' state.apply foo test=True and you should see that package.bar would also be applied.
The salt docs also include a section titled Moving Beyond a Single SLS which discusses using include and extend to glue multiple states together.
Splitting up an SLS for organizational purposes is also a common use for init.sls
As a brief aside, there are some states which go the other direction and allow allow you to run execution modules from within an SLS. A few examples are salt.states.module.run and salt.states.saltmod.state, though the uses for these are far more specialized than what it seems you're trying to do.
Over the past few weeks I have been getting into Ada, for various different reasons. But there is no doubt that information regarding my personal reasons as to why I'm using Ada is out of scope for this question.
As of the other day I started using the gprbuild command that comes with the Windows version of GNAT, in order to get the benefits of a system for managing my applications in a project-related manner. That is, being able to define certain attributes on a per-project basis, rather than manually setting up the compile-phase myself.
Currently when naming my files, their names are based off of what seems to be a standard for the grpbuild, although I could very much be wrong. For periods (in the package structure), a - is put in the name of the file, for underscores, an _ is put accordingly. As such, a package by the name App.Test.File_Utils would have a file name of app-test-file_utils: .ads and .adb accordingly.
In the .gpr project file I have specified:
for Source_Dirs use ("app/src/**");
so that I am allowed to use multiple directories for storing my files, rather than needing to have them all in the same directory.
The Problem
The problem that arises, however, is that file names tend to get very long. As I am already putting the files in a directory based on the package name contained by the file, I was wondering if there is a way to somehow make the compiler understand that the package name can be retrieved from the file's directory name.
That is, rather than having to name the App.Test.File_Utils' file name app-test-file_utils, I would like it to reside under the app/test directory by the name file_utils.
Is this doable, or will I be stuck with the horrors of eventually having to name my files along the lines of: app-test-some-then-one-has-more_files-another_package-knew-test-more-important_package.ads? Granted, I have not missed something about how an Ada application should actually be structured.
What I have tried
I tried looking for answers in the package Naming configuration of the gpr files in the documentation, but to no avail. Furthermore I have been browsing the web for information, but decided it might be better to get help through Stackoverflow, so that other people who might struggle with this problem in the future (granted it is a problem in the first place) might also get help.
Any pointers in the right direction would be very helpful!
In the top-secret GNAT documentation there is a description of how to use non-default file names. It's a great deal of effort. You will probably give up, use the default names, and put them all in a single directory.
You can also simplify much of the effort by using GPS and letting it build your project file as you add files to your source directories.
i have this tree structure:
repository/modules/module1
repository/modules/module2
repository/modules/module..
repository/apps/application1
repository/apps/application2
repository/apps/application..
where the applications are using some modules.
now, I'd like to put some resources inside a module (like a very colorfull icons inside a widget used by several applications) but.. something gets wrong.
inside the module CMakeLists.txt if I use only:
set(${MODULE_NAME}_RCS
colors.qrc
)
...
qt4_add_resources (${MODULE_NAME}_RHEADERS ${${MODULE_NAME}_RCS})
no qrc_colors.cxx are created anywhere. so I've tried to add:
ADD_EXECUTABLE (${MODULE_NAME}
${${MODULE_NAME}_RHEADERS}
)
but.. I get this weird error:
CMake Error at repo/modules/ColorModule/CMakeLists.txt:51 (ADD_EXECUTABLE):
add_executable cannot create target "ColorModule" because another
target with the same name already exists. The existing target is a static
library created in source directory
"repo/modules/ColorModule". See documentation for
policy CMP0002 for more details.
(I've changed the path of the error of course)
so.. don't know what to think because i'm new both to cmake and qt..
what can i try?
EDIT:
if I add the ${MODULE_NAME}_RHEADERS and ${MODULE_NAME}_RCS in the add_library command the qrc_colors.cxx is created BUT it is in repository/modules/module1/built and not copied in the application built directory...
There is at least two errors in your code.
1) It is usually not necessary to use ${MODULE_NAME} everywhere like that, just "MODULE_NAME". You can see that the difference is the raw string vs. variable. It is usually recommended to avoid double variable value dereference if possible.
2) More importantly, you seem to be setting ${MODULE_NAME} in more than one executable place, which is "ColorModule" according to the error output. You should have individual executable names for different binaries.
Also, the resource file focus is a bit of red herring in here. There are several other issues with your project.
You can cmake files as CmakeLists.txt instead of CMakeLists.txt which inherently causes issues on case sensitive systes as my Linux box.
You use Findfoo.cmake, and find_package(foo) for that matter, rather than the usual FindFoo.cmake convention alongside find_package(Foo).
Your FindFoo.cmake is quite odd, and you should probably be rewritten.
Most importantly, you should use config files rather than find modules.
Documentation and examples can be found at these places:
http://www.cmake.org/Wiki/CMake/Tutorials#CMake_Packages
https://projects.kde.org/projects/kde/kdeexamples/repository/revisions/master/show/buildsystem
When you would like use a find module, you need to have that at hand already. That will tell you what to look for, where things are, or if they are not anywhere where necessary. It is not something that you should write. You should just reuse existing ones for those projects that are not using cmake, and hence the find modules are added separately.
It is a bit like putting the treasure map just next to the treasure. Do you understand the irony? :) Once you find the map, you would automatically have the treasure as well. i.e. you would not look for it anymore.
When working with cmake, is it better to work with one large CMakeLists.txt in the root of the project, or as seems to be seen in some places, having one in each subdirectory too?
I would assume something along the lines of for large projects, having one in each directory is better.
If so, where should the threshold be?
I would certainly go for using multiple CMakeListst.txt files.
As a rule of thumb I think you should go for one CMakeLists.txt (and thus subdirectory) per target. So, each library or executable has its own CMakeLists.txt.
You can then create one "master" CMakeLists.txt that includes all the others using the add_subdirectory call. If you take care that you order these statements correctly, you can easily reference previously defined targets in the other CMakeLists.txt file.