Goal
I'd like to launch a CLI program closely related to my flutter project, i.e., the program is saved somewhere near the flutter project folder.
My end goal here, is so that I could release a separate problem outside of the flutter app bundle at a fixed location relative to the bundle, e.g., same parent folder, while flutter-built exe can still find the program automatically. The solution targets Windows/macOS.
Expectation
I expect that I could retrieve a standard project path, such as the path to main.dart, and go from there using relative paths. I was so spoiled by Python's __file__ and wish to see something similar. This is also fairly easy to do with Windows/macOS native API, like this
For example, say I created a project under this folder
/path/to/my/flutter_project
I expect to call a Dart API to get the path of main.dart like this
/path/to/my/flutter_project/lib/main.dart
Observation
According to this answer The closest thing I got with flutter, is
import 'dart:io' as io;
Uri filePath = io.Platform.script.resolve('.');
however, puts me to a prescribed location:
// macOS
~/Library/Containers/com.example.flutterRelpath/Data/
This is the package data folder instead of the project folder.
If I query the script itself using
io.Platform.script.path
I get
~/Library/Containers/com.example.flutterRelpath/Data/main.dart
which is not the physical location of the script.
Question
Does it mean that I would need an installer to install the CLI program there or prepare a UI for the user to specify the location before I could use it? This seems a lot of trouble.
There is no reason to obtain the path of the script, nor does that make sense to do in a compiled application as the source files are not directly used at runtime.
You can simply use a relative path to reference whatever file/executable you want.
final uri = Uri.file('relative/file/path');
This will give you a Uri to the path file in the file folder in the relative folder, which would be at the same level as your executable.
├── executable.exe
├── relative
│ └── file
│ └── path//The Uri will refer to HERE
In order for this to be a relative, the passed path must not start with a path separator. So it should not be:
final uri = Uri.file('/relative/file/path');
Have a look at the dcli package and the DartScript and DartProject classes. they have methods designed to provide exactly this type of path information.
E.g.
DartProject.self.pathToProjectRoot
Related
When I develop a project that output is a shared library or executable, normally, I will use include_directories in the CMakeLists.txt of root directory. In such case, before I include a header within a translate unit, I can't use angle brackets to let headers include each other. I think it is because files in include_directories is not a part of project. I can fix this by using relative path, but when I have to import external project, this can not fixed easily.
Assume that I have a external project with a root CMakeLists.txt, which has this snippet
add_library(mylib INTERFACE)
target_include_directories(mylib INTERFACE .)
and the directory seems like this
└──external
├───mylib.hpp
└───CMakeLists.txt
I want to import this project, and I'm writing a header-only project. The file tree seems like this
├──external (above)
├──include
| ├──header.hpp
| └──CMakeLists.txt
└──CMakeLists.txt
The CMakeLists.txt in root directory is simply add_subdirectory(include), and here is the CMakeLists.txt in folder include
add_library(Header INTERFACE)
target_include_directories(Header INTERFACE .)
target_link_libraries(Header INTERFACE mylib)
Theoretically, I can now include mylib.hpp by #include <mylib.hpp>, but it is not the case. VSCode tells me it can't find this header file. As much as I know, the only way to solve this is add a translate unit and let the implementation code include the header.hpp. I have tested this several time. VSCode won't report this error as long as I add a cpp file and include that header, and once I remove the cpp file, the error appears again.
By the way, I have set "C_Cpp.default.configurationProvider": "ms-vscode.cmake-tools" in configuration file of vscode.
Please tell me how to fix this without a translate unit.
This question already has answers here:
How do I do a basic import/include of a function from one module to another in Rust 2015?
(3 answers)
Split a module across several files
(7 answers)
How can I include a module from another file from the same project?
(6 answers)
Closed 5 years ago.
How do I include a file with the full path my_project/src/include_me.rs in main.rs?
I've checked the dependencies guide, and all of them appear to be including a binary. I've also checked "The Book", but none of the examples there end in ".rs" either.
How do I make include_me.rs compile with the rest of the project?
There are basically two (main) ways in Rust to include code from somewhere else:
1. "Including" internal code
If your include_me.rs belongs to your project, you should move it to the same folder main.rs lies in:
└── src
├── include_me.rs
└── main.rs
Then you can write this in your main.rs:
mod include_me;
fn main() {
// Call a function defined in the other file (module)
include_me::some_function();
}
A mod declaration makes the Rust compiler look for the corresponding .rs files automatically!
So everything that belongs to your project, belongs in the same folder (or a subfolder thereof) as the folder where main.rs (or lib.rs) is lying. The files are then "included" via the module system. To read a good introduction into modules, please read the chapter on modules in the Rust book. You could also check out Rust by Example on that topic. The module system is pretty central and thus important to learning Rust.
2. "Including" external code
If your include_me.rs is something that doesn't belong to your actual project, but is rather a collection of useful things you are using in multiple projects, it should be seen as a library. To include code of such external libraries, you have to include it as an extern crate. And to make your life easier, you really want to use Cargo!
So let's prepare your include_me.rs as Cargo library project. You need the following file structure (which is automatically generated by cargo new my_library --lib):
. my_library
├── Cargo.toml
└── src
└── lib.rs
Now copy all the contents from include_me.rs into lib.rs (it is just convention to call the root file of a library project lib.rs). Let's say that the my_library folder's full path is ~/code/my_library.
Now let's prepare your main project's Cargo project. It has a similar file
structure (but a main.rs instead of lib.rs, because it's a executable-project, not a library-project):
. my_project
├── Cargo.toml
└── src
└── main.rs
To declare your dependency on my_library, you have to put this into your Cargo.toml:
[package]
name = "my_project"
version = "0.1.0"
authors = ["you"]
edition = "2018"
[dependencies]
my_library = { path = "~/code/my_library" }
You can also use relative paths ("../my_library"), but it only makes sense if you know that the two projects always stay where they are, relative to one another (like if they are both managed in the same repository).
Now you can, in your main.rs, write:
use my_library::some_function;
fn main() {
// Call a function defined in the other file (extern crate)
some_function();
}
If you want to upload any of those two projects, you have to interact with crates.io (or another crates registry, if your company has one), but this is another topic.
(Note: some time ago, it was necessary to write extern crate my_library; inside main.rs. This is not necessary anymore, but you might find old code with extern crate declarations.)
Any other ways?
Yes, but you shouldn't use those. There is the include!() macro which allows you to verbatim include other files, just like the #include from C-land. However, it is strongly discouraged to use this in situations where the module system would be able to solve your problem. include!() is only useful in very special situations, often linked to a more complex build system which generates code.
I want to deploy some front end assets to the local web root of a site using file replacement. I can't seem to get it to work with a relative path in the target location field though. Is it possible to do this though tds or should I use a post build event instead?
The reason these assets aren't included in a project is that they are part of a third party solution but we still want this tracked in source control to try to make the project setup easier.
Most developer machines will be set up the same way for this project with the same file structure but I think it's a little more flexible if I can make the target a relative path so I don't need to worry about differences like drive letters and such.
The folder structure is as follows:
repo
folderToCopy
sitecore
webroot
I have tried the following using ..'s based on what tds changed my source location to be while using the "Make selected Source Location relative" option (changed it from an absolute path to ..\folderToCopy\):
../../Sitecore/Website
/../../Sitecore/Website
..\..\Sitecore\Website
\..\..\Sitecore\Website
From my understanding, TDS does the file replacement based on the files published from the associated Website project.
You can then have relative replacements such as the following:
<Replacement Include=".\assets\folderToCopy\myFile.txt">
<TargetPath>.\assets\targetFolder\myFile.txt</TargetPath>
<IsFolder>False</IsFolder>
<IsRelative>True</IsRelative>
</Replacement>
I have not been able to successfully get TDS to use the file replacement with files that are in source control but not in the project.
My suggestion would be to set up a build event that will copy these files to the correct location, or to create a nuget feed for them and pull them in as nuget references.
I'm trying to use import a package for internal use, but I have been having some issues.
My directory structure looks like this:
app/
model/
file1.go
file2.go
...
main.go
When I try to build the program, I get an error that looks something like this:
/usr/local/go/src/pkg/model (from $GOROOT)
I want to be able to call the model programs in any of my other programs in the app simply using:
import "app/model"
What are my options when it comes to doing this?
You import from GOPATH level .. all of your packages should live there.
For example, assuming your application is here:
$GOPATH/src/dtrinh100/app/
..and your package you wish to import is here:
$GOPATH/src/github.com/other/package
Your import would be:
import "github.com/other/package"
You should review the literature around what the GOPATH environment variable is all about. When beginning Go, it is important you understand its purpose and initially, you should place all of your projects/packages inside of the GOPATH.
When you import a custom package, Go looks for its definition in each workspace listed in the GOPATH environment variable. Your custom package should be defined in a src subdirectory.
If you keep your code in a source repository somewhere, then you should use the root of that source repository as your base path. For instance, if you have a GitHub account at github.com/user, that should be your base path.
Note that you don't need to publish your code to a remote repository before you can build it. It's just a good habit to organize your code as if you will publish it someday. In practice you can choose any arbitrary path name, as long as it is unique to the standard library and greater Go ecosystem.
You should use github.com/user as our base path. Create a directory inside your workspace in which to keep source code:
$ mkdir -p $GOPATH/src/github.com/user
You can look at How to Write Go Code for more details.
"The configuration file C:\mywebapp\mydoamin.dll.config could not be found."
mywebapp domain is the originating code. mydomain is the executing code that references FileConfigurationSource and that is where the config file is located. I'm expecting it to look in mydomain... c:\mydomain\mydomain.dll.config instead. Am I missing something?
If you are using a relative path with FileConfigurationSource it is going to look for the file in the AppDomain.CurrentDomain.BaseDirectory directory. Actually, it will combine the BaseDirectory with the relative path given as the constructor argument to try to locate the file.
You either need to deploy the configuration file into the web root directory (based on your current code) or use an absolute path.