How to organize folder structures in app/views folder without conflicting with other application folders? For example,
app/
controllers/
org/
OrgInfo.scala
views/
org/
a.scala.html
user/
b.scala.html
I found out that b.scala.html can no longer see org.OrgInfo class. When I do #import org.OrgInfo at b.scala.thml, it throws an error that it can't find OrgInfo under views.html.org. What's wrong?
Scala accepts relative packages, this means that if you try to use org like that it refers to the views.org package, you can solve this by providing the fully qualified class name:
#import controllers.org.OrgInfo
I think johanandren provided you with the correct answer.
So you should not start your import clause from org. org in your case is a sub-package of controllers. Use the absolute package name controllers.org._
Related
Kotlin packages are written package one.two.three, and they usually match the folder structure (e.g. one/two/three) of the project, but they don't have to match the folder structure. What is the motivation behind the decision to allow packages to not match the folder structure? What use cases does it enable?
The obvious use case is that now you can organize your code in whatever packages and you are not forced to have the same folder structure. Other than that I don't see any other use case. Why have they done it? Not sure and it does not seem to be something useful or wanted because the recommendation is still to match packages with the folder structure (even IntelliJ warns you when you have a package that does not match the folder structure.
It seems to me to be a feature that was not needed or even wanted by the community.
I've been following the docs at https://cmake.org/cmake/help/latest/manual/cmake-packages.7.html#creating-packages to create an installable package.
After adding the namespace to my project at the same place as suggested at that link, I was succesfully able to link using that namespace.
However, simply taking the namespace away with just the library name, I was still able to link against my library.
What is the use of the namespace in cmake if it isn't required? Or have I set up something incorrectly? I really don't want consumers of my library to just be able to type "graphics" - they should have to type the full "myLib::graphics" out.
The use is so that it is possible to use the namespace version. This is useful when a library is used via add_subdirectory/FetchContent, so the usage can be written the same way if it were to be switched to use find_package (which will import targets with the namespace prefix). If you're worried about target name clashes, just prefix your target names like myLib_graphics, and then use the EXPORT_NAME target property to remove the prefix for the export.
I am using Mogenerator to automatically create subclasses for my Entities in Core Data.
I had acted upon a recommendation I read to store the files in subdirectories within my project (since I will have many). Used the following arguments when running the script:
cd Project
mogenerator --template-var arc=true -m Project.xcdatamodeld/Project.xcdatamodel/ - M CoreData/Machine/ -H CoreData/Human/
I added these to my project as a folder reference, as the script may add files to match my model and I don't want to have to add them to my project manually.
The directory structure for both the created files are like this:
Project/CoreData/Human/Entity.h
Project/CoreData/Machine/_Entity.h
I need to import "_Entity.h" inside of "Entity.h". The problem is, it's not in the same or lower directory and I don't know how to do a relative reference to a higher directory. I'm forced to use an absolute directory all the way from /Users.. which works, but it includes my username etc. so I'd rather not.
Question: How can I import _Entity.h from Entity.h using relative reference?
Bonus question: Is it possible to have mogenerator automatically use the proper reference? I mean, I'm clearly telling it where to put both files and it's doing it, but still only puts the following in Entity.h:
#import "_Entity.h"
...and I get an error.
Thanks in advance,
Pat
".." (without the quotes) represents the directory that's "one level higher". Use this to go to "CoreData", then to "Machine".
Try this:
#import "../Machine/_Entity.h"
I'm not sure if it'll work, but it's worth a try!
I would like to add into project some files that shouldn't be compiled. I mean mainly text files with for example notes, concepts, comments etc.
I realized that it is possible only at module level. But it is not very convenient. I'd rather prefer to keep them on project level. Is it possible in any way?
And if not:
I have another idea: to create special module, name it for example "other_stuff", do not create src directory and put files there. Is it ok? I'm afraid of potential compilation problems when one of modules is artificial, with no sources but still has sdk assigned (it is probably impossible to leave module without sdk assigned).
While generating artifacts you can add any file into your artifact. Also, in modules you can have folders not declared as source, and they will not be compiled.
I am trying to clean up some of my projects, and one of the things that are puzzling me is how to deal with header files in static libraries that I have added as "project dependencies" (by adding the project file itself). The basic structure is like this:
MyProject.xcodeproj
Contrib
thirdPartyLibrary.xcodeproj
Classes
MyClass1.h
MyClass1.m
...
Now, the dependencies are all set up and built correctly, but how can I specify the public headers for "thirdPartyLibrary.xcodeproj" so that they are on the search path when building MyProject.xcodeproj. Right now, I have hard-coded the include directory in the thirdPartyLibrary.xcodeproj, but obviously this is clumsy and non-portable. I assume that, since the headers are public and already built to some temporary location in ~/Library (where the .a file goes as well), there is a neat way to reference this directory. Only.. how? An hour of Googling turned up blank, so any help is greatly appreciated!
If I understand correctly, I believe you want to add a path containing $(BUILT_PRODUCTS_DIR) to the HEADER_SEARCH_PATHS in your projects build settings.
As an example, I took an existing iOS project which contains a static library, which is included just in the way you describe, and set the libraries header files to public. I also noted that the PUBLIC_HEADERS_FOLDER_PATH for this project was set to "/usr/local/include" and these files are copied to $(BUILT_PRODUCTS_DIR)/usr/local/include when the parent project builds the dependent project. So, the solution was to add $(BUILT_PRODUCTS_DIR)/usr/local/include to HEADER_SEARCH_PATHS in my project's build settings.
HEADER_SEARCH_PATHS = $(BUILT_PRODUCTS_DIR)/usr/local/include
Your situation may be slightly different but the exact path your looking for can probably be found in Xcode's build settings. Also you may find it helpful to add a Run Script build phase to your target and note the values of various settings at build time with something like:
echo "BUILT_PRODUCTS_DIR " $BUILT_PRODUCTS_DIR
echo "HEADER_SEARCH_PATHS " $HEADER_SEARCH_PATHS
echo "PUBLIC_HEADERS_FOLDER_PATH " $PUBLIC_HEADERS_FOLDER_PATH
.
.
.
etc.
I think that your solution is sufficient and a generally accepted one. One alternative would be to have all header files located under an umbrella directory that can describe the interface to using the depended-on libraries and put that in your include path. I see this as being similar to /usr/include. Another alternative that I have never personally tried, but I think would work would be to create references to all the headers of thirdPartyLibrary from MyProject so that they appear to be members of the MyProject. You would do this by dragging them from some location into MyProject, and then deselecting the checkbox that says to copy them into the project's top level directory. From one perspective this seems feasible to me because it is as if you are explicitly declaring that your project depends on those specific classes, but it is not directly responsible for compiling them.
One of the things to be wary of when addressing this issue is depending on implementation-specific details of Xcode for locating libraries automatically. Doing so may seem innocuous in the meantime but the workflows that it uses to build projects are subject to change with updates and could potentially break your project in subtle and confusing ways. If they are not well-defined in some documentation, I would take any effect as being coincidental and not worth leveraging in your project when you can enforce the desired behavior by some other means. In the end, you may have to define a convention that you follow or find one that you adopt from someone else. By doing so, you can rest assured that if your solution is documented and reproducible, any developer (including yourself in the future) can pick it up and proceed without tripping over it, and that it will stand the testament of time.
The way we do it is to go into build target settings for the main project and add:
User Header Search Path = "Contrib"
and check that it searches recursively. We don't see performance problems with searching recursively even with many (10-15 in some projects) dependencies.