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...
Related
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.
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
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.
Here is my problem>
We currently have several Ecore models for our applications. One of the Ecore models (mainModel.ecore) has stuff that is common in all the rest of the models. So, what i want to do is have all the other models reference the contents of that one model so we do not have to constantly copy the contents of that one model into all the models every time there is a change.
Is this possible and how can I do this?
(I am very new to Ecore and still do not understand a lot of the terminology.)
EDIT:
How do i get the EcoreUtil.getRootContainer to return the the container of the loaded resource? I need to have that location so that i can resolve certain paths from that root. This may resolve my issue.
Here is what i attempted so far:
I tried "load resource..." by loading the mainModel.ecore into all the other models and deleting the local references. There were a lot of places that i had to fix after doing this and i did. After re-generating the source and trying to compile there are places where it tried accessing the "dotpath" that was local to the original file and i do not know how to change that "dotpath" to reference the "loaded resource". So it is not able to resolve those paths.
Thanks!
You'll generally get answers about EMF more readily by using the EMF newsgroup (eclipse.tools.emf) which is web accessible via
http://www.eclipse.org/forums/index.php/f/108/
Your problem isn't so clear. I don't understand how the compiled code accesses anything via a "dot path". I know if you load a resource and refer to it's contents you'll generally end up with relative paths, but those are normally resolved during loading to an absolute URI. Of course the referencing resource itself needs to be loaded with an absolute URI, but the generator does that properly...
I'm trying to come up with a way to make it easy to switch out our "mock" data services and our live ones. Basically, we'll have live servers with real web services, but for whatever reason, a developer may want to load data from static files (file urls).
I figured I would solve this problem by creating categories that override the methods that fetch the data, thus leaving original code untouched (it has no concept of the "mock" data). I don't want to litter my code with #ifdef.
I can put an #ifdef at the very beginning of each file that has categories in it, and I can set a custom flag in the configuration settings, but I'd rather just have a way to include or exclude the files depending on the configuration. Is that possible? How do you solve this problem?
See http://lists.apple.com/archives/xcode-users/2009/Jun/msg00153.html
The trick is to define EXCLUDED_SOURCE_FILE_NAMES in the configuration you want to exclude the files from, and set the value of that custom build setting to a list of the file names (or a pattern that matches those, and only those, file names).
I would recommend creating two targets one of which has the mock categories included and another one which does not.
When you want to test, just build the target containing the mock categories. Everything else can remain identical.
If you would like to add a file but do not wont to compile it. Go to (for all your targets) project>build phases>compile source and take out the file that you do not want to compile.