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.
Related
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.
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!
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.
In Qt, it is possible to specify an Info.plist file to use when building on Mac, as follows:
QMAKE_INFO_PLIST = MyInfo.plist
This replaces the Qt auto-generated Info.plist file with another one.
Rather than replace Qt's auto generated one entirely, is it possible to add individual entries?
I don't think it will make little practical difference but I'd like to be able to do it because I feel it would be "tidier" to just add the additional items I want rather than brutally replace the whole file.
Unfortunately this is impossible. But Qt makes your life easier with some variables that you can use in plist file. From Qt documentation:
In the .plist file, you can define some variables, e.g., #EXECUTABLE#,
which qmake will replace with the actual executable name. Other
variables include #ICON#, #TYPEINFO#, #LIBRARY#, and #SHORT_VERSION#.
Find a file named 'Info.list.app'. This is the template of Info.list. You can use it as a start point and append you own entries. It is typically location like Qt5.7.0/Src/qtbase/mkspecs/macx-ios-clang/Info.plist.app in your QT root dir.
See Qt documentation for more detail.
I'm seeing some of SF2 components have a folder named stubs placed inside the Resources/ folder. I wonder what is it for? And for my bundle I need to define some global functions, would the stubs folder be a good location to place the files containing these functions?
It seems there are a few meanings for stub. The most relevant I could find was one that described a stub as 'code that is used to stand in for some other programming functionality'.
I.e. acting as a substitute for code that is yet to be developed, or to simulate the behaviour of existing code that isn't usable (or viably usable) under certain circumstances, for example, in a development environment.