In a library package, I would like to move some source files from the "Sources" folder to subdirectories, without changing language semantics (module name, visibility, etc).
Now I have a layout like:
LibraryProject
Sources
AnotherThing.swift
FooProtocol.swift
SomeFoo.swift
OtherFoo.swift
BarProtocol.swift
SomeBar.swift
OtherBar.swift
And, if I change it to something like:
LibraryProject
Sources
AnotherThing.swift
Foo
FooProtocol.swift
SomeFoo.swift
OtherFoo.swift
Bar
BarProtocol.swift
SomeBar.swift
OtherBar.swift
Then, invoking swift build fails:
error: the package has an unsupported layout, unexpected source file(s) found: [...]
Is this layout possible? I only found this issue https://bugs.swift.org/browse/SR-66 that suggests that it is not, but I cant find confirmation (or reason) in the documentation.
Thanks
I have found two options that work for Swift projects on Linux, either all .swift files must be directly in the Sources folder, or there must be one subfolder in Sources and as many subfolders within that as you like.
Swift builds a Module out of the top-level subfolder in Sources and includes all the subfolders within that.
I don't believe it is possible to have two Modules within the same Sources folder, as a Module would not recognise any code outside itself.
So in your example a working structure would be:
LibraryProject
Sources
YourModuleName
AnotherThing.swift
Foo
FooProtocol.swift
SomeFoo.swift
OtherFoo.swift
Bar
BarProtocol.swift
SomeBar.swift
OtherBar.swift
Here is the Folder structure for Swift package
And Here i have mentioned how to add the resources and add lines in Package
Related
I'm trying to understand mapping of URIs to files. Let's take this URI:
modelica://foo.bar/file.png
Is it correct that there are two possible locations for file.png?
It could be either
$MODELICAPATH/foo/file.png if file $MODELICAPATH/foo/bar.mo exists.
Or
$MODELICAPATH/foo/bar/file.png if file $MODELICAPATH/foo/bar/package.mo exists.
Likely Section "13.2.3 External resources" of the Modelica Language Specification helps.
A little modification of your example should help to understand how it works. Using modelica://foo/bar/file.png refers to foo as top-level package/library. The library the path is resolved when it is loaded in the simulation environment. In case you store the library hierarchically (i.e. every package is represented as folder, each model is a file) bar would be a subfolder within the libraries root directory. file.png would be the file name within bar.
This is different if the package is stored as a single file, but as this has several disadvantages I would recommend to go with the hierarchical option.
No need to edit $ModelicaPath$ if the library is loaded.
Usually pictures etc. are put into a Resources folder within the library. This folder can contain additional folders like data, Images, Scripts...
There is information on the web as well as here on the topic related to the using external file resources in CDT Eclipse: C/C++ and H files located somewhere else in the files system. All the described methods run along two methods:
creation within the project space the virtual linked files which point to
the locations of the actual files without copying them
adding the location of the external referenced resource in the
Project->Properties->C/C++ general->Paths and Symbols and related
Project->Properties-> C/C++ Build (link folders and includes)
I am not sure if the 1st method is always enough without adding the 2nd, but seems the 2nd builds well without the 1st.
My question is about a comparison of the two. Are those methods intended to be used similarly or each one is preferred in some cases?
Is each method self sufficient without applying the other?
This forum thread
https://www.eclipse.org/forums/index.php/t/1087314/ suggests that for the include files the 1st method might not even be sufficient as the Build Settings should still be updated (2nd method) to include the linked H files...then may be the 1st method is irrelevant?
You would typically use the first method if you want to edit the externally-located files as part of your work on the project, and the second method if they're just dependencies that you use without modifying.
On a technical level, the difference is that with the first method the files will be part of the project model, and so will e.g. show up as candidates in Open Resource, while with the second method they wouldn't. Another difference is that with the first method, the files are indexed independently, while with the second method the files are only indexed by virtue of being included by files in your project (so e.g. .cpp files in those directories typically wouldn't be indexed with the second method at all).
Update: answers to questions from the comment
Is the 1st method sufficient enough in all cases without updating Paths and Symbols Property ?
No, if there are header files located in the linked directory that are included by files in your project using include paths that are not relative to the current directory (so not just #include "foo.h" in the same directory, #include "../foo.h" in a child directory, etc., but #include <bar/foo.h> in some other directory), you still want to specify those include paths in Paths and Symbols.
CDT's indexer does have an "Allow heuristic resolution of includes" option (specified in Preferences -> C/C++ -> Indexer) that may allow you to avoid adding the paths to Paths and Symbols, but note that (1) this affects the indexer only, not the build (which may be fine if you're using your own makefiles for the build), and (2) as it's heuristic, it's not perfect, e.g. if you have headers with the same name in different directories it can get confused. For best accurracy, I recommend unchecking "Allow heuristic resolution of includes", and always specifying include paths explicitly.
Also can the 2nd method be sufficient in itself if referenced files to be used AS IS without modification?
I don't see why not.
I have created a small Modelica library of my own. The way I have created it is in a single file. But I would like to make it a proper Modelica Library, as in the one with multiple directories for each subpackages.
So this is what i followed. File > New Modelica Class > Specialization - Package > Unchecked Save contents in one file. I copied the entire package code from the single file library, pasted it here and saved it. while doing so, I've noticed that the library lost most of its extends clauses, few models went missing.
Have I followed the correct procedure to create the library or did I do something wrong?
Can anyone point me towards the right direction?
#MSK, I cannot help you with OpenModelica as I work with Dymola. I did however recently split a single-file library (called package in Modelica) into several files manually. I did this so that the library hierarchy is represented in the file system hierarchy (i.e. several subfolders and .mo files in a library folder). For 35,000 lines of code this took roughly 10 hours. Just follow these steps:
create folder with same name as library
in this folder, create a text file "package.mo"
"package.mo" has to start with the statement
within ;
package [name of your package, i.e. the folder name...without the brackets];
now you want to create a subclass within this package. To do this create another folder containing a text file called "package.mo"
start this "package.mo" with
within [name of your package];
and declare the model as usual.
continue all the way down your library hierarchy
at the lowest hierarchy level you no longer need to create folders. You can simply create a .mo with the name of the lowest level class. As usual, start this file with
within [name of your package].[subclass1].[subclass2];
For an example of implementation please refer to the Physiolibrary found at https://www.modelica.org/libraries or the Modelica Standard Library which also uses this structure.
In Java, you have to put source files in the directory structure corresponding to their package. foo.bar.Baz has to live in foo/bar/Baz.java.
In Scala, that requirement is relaxed. If all your classes in a particular project are in package foo.bar, you might just want them to live in the root source directory.
But IDEA flags this as an error, and forces me to put Scala classes in their Java-style directory when, for example, I copy or move classes. Is there a way to turn off this behavior?
Go Settings -> Scala -> Other settings -> Resolve to all classes, even in wrong directories.
I decided to move some of my jsp files into separate files with special filetype (named *.part). Now I imported that files to be handled like jsp's to color them and make the coding more convenient.
I can find the new extension in "preferences/web/jsp/Add this suffix". Some comparable, registered file types can be found under e.g. pref./web/html or pref./web/css.
But how can I delete these types again? How to manage these files?
I found the answer to my above-mentioned question:
In Eclipse: Preferences->General->Content-Types->Text->[Remove/Add file here]