I have troubles resolving my module imports. Here is my file structure:
.
|-- scenes
| |-- libs
| | |-- mod.rs
| | `-- components.rs
| |-- mod.rs
| `-- scene.rs
`-- main.rs
I can't import the module libs in scene.rs. I think I don't get it the module logical. Any help would be very appreciable.
if I try to do mod libs; in scene.rs
error[E0583]: file not found for module `libs`
--> src/scenes/scene.rs:2:5
|
2 | mod libs;
| ^^^^
|
= help: name the file either scene/libs.rs or scene/libs/mod.rs inside the directory "src/scenes"
Contents files:
main.rs
mod scenes;
let sc = scenes::scene::Scene{};
scenes/scene.rs
mod libs; // errors
pub struct Sphere {
pub center: libs::components::Point
}
pub struct Scene {}
scenes/mod.rs
pub mod scene;
pub mod libs;
scenes/libs/components.rs
pub struct Point {}
scenes/libs/mod.rs
pub mod components;
Instead of mod libs, write use crate::scenes::libs.
The Rust 2018 Edition has changed the module system slightly to help clarify situations such as this.
Your directory should be restructured like so:
main.rs
scenes.rs
scenes
| libs.rs
| libs
| | components.rs
| scene.rs
The main difference here is that mod.rs files are now extracted from their folder and named appropriately.
PRE-RUST-2018 - NOV 2018
Instead of mod libs, write use scenes::libs.
The error message is telling you is you're trying to declare the existence of a submodule of scene that does not exist. Instead, you want to import (with use) the libs module which is accessed by scenes::libs from the crate root.
Related
I'm stuck when learning how to access a module. I'm trying to insert a folder other than src into src. It's not working and it gives me an error. Here this is my project tree.
$ Project1
.
|-- src
| |-- main.rs
| |--FolderinSrcFolder
| |--folderinsrcmodule.rs
|
|--anothersrc
| |--mod.rs
|
|-- rootmodule.rs
|-- Cargo.toml
|-- Cargo.lock
How can I access anothersrc/mod.rs src/main.rs? How can I access rootmodule.rs from src/main.rs?
I already read the Rust documentation.
Idiomatic solution
Don't. Put all of your source code into the src directory. You could also create another crate with its own src directory. Don't fight these idioms and conventions, it's simply not worth it.
See also:
Rust package with both a library and a binary?
Literal solution
This directly answers your question, but I strongly recommend that you don't actually use this!
Layout
.
├── Cargo.toml
├── bad_location.rs
└── src
└── main.rs
src/main.rs
#[path = "../bad_location.rs"]
mod bad_location;
fn main() {
println!("Was this a bad idea? {}", bad_location::dont_do_this());
}
badlocation.rs
pub fn dont_do_this() -> bool {
true
}
The key is the #[path] annotation.
See also:
How can I use a module from outside the src folder in a binary project, such as for integration tests or benchmarks?
How do I tell Cargo to run files from a directory other than "src"?
How do I import from a sibling module?
I have three files in src/, like so:
lib.rs
pub mod first
first.rs
fn hello() {}
main.rs
pub mod lib
This gives me an error saying:
error[E0583]: file not found for module `first`
--> src/lib.rs:1:9
|
1 | pub mod first;
| ^^^^^
|
= help: name the file either lib/first.rs or lib/first/mod.rs inside the directory "src"
Now, if I remove pub mod lib from main.rs, everything compiles fine.
I don't understand why this is happening.
The help that compiler says is very meaningful.
When you write pub mod first; inside of a lib.rs it checks for the first.rs file or first folder inside a lib folder and a mod.rs file.
Please note that mod.rs usages are changed with Rust 2018. Reference
Now, if I remove pub mod lib from main.rs, everything compiles fine.
When you remove pub mod lib; from your main,
You basically say that this code will not be used in production therefore it is not needed to compile even. So basically the code will not included to compile.
This is why it works when you remove the pub mod lib;
I have an Android Studio project with a general layout as follows:
Project/
|
+-- app/
| |
| +-- src/main/cpp/
| | |
| | +-- native-lib.cpp
| | +-- CMakeLists.txt
| |
| +-- build.gradle
| +-- CMakeLists.txt
| |
+-- sibling-lib/
| |
| +-- src/main/cpp/
| | |
| | +-- partA/CMakeLists.txt
| | +-- partB/CMakeLists.txt
| | +-- partC/CMakeLists.txt
| |
| +-- build.gradle
| +-- CMakeLists.txt
|
+-- build.gradle
+-- settings.gradle
sibling-lib is a third-party library comprised of multiple parts, each with separate sources and common headers, each of which is compiled into either a static or shared library, using the associated CMake file, and included as a subdirectory by the top-level library CMake file. Most of those parts are dependent on other parts.
The goal is to compile and link the parts of sibling-lib into library files within an Android Library (.aar) and use those libraries from the native files within the main app (e.g. native-lib.cpp). I have been able to compile each of the parts as a static library, with the final part linked together as a shared library (using target_link_libraries() on that part), and then load the library from the app's Java code. However, when I try to call any of sibling-lib's functions, I receive reference errors when compiling.
How should I configure the CMake and gradle files (for both the app and library) to properly compile and set up my project? Is there, however, a better way to configure the project to obtain the desired result?
I have a static library in my project, lets call it libcommon, and I am including a header file from this library #include <libcommon/common.h>, not the angular brakets, not upper quotes. How can I configure CMakeLists.txt so that it find the include?
Assume the directory structure is like this:
-- root/
\-- src/
| |-- libcommon/common.h
| \-- main/main.c
\-- CMakeLists.txt
I tried:
include_directories (... src)
and:
include_directories (... ${main_SOURCE_DIR}/src)
but the libcommon/common.h was not found.
I figured it out while writing the question:
Instead of using just include_directories, I had to use target_include_directories:
target_include_directories(main PRIVATE src)
or:
target_include_directories(main PRIVATE ${main_SOURCE_DIR}/src)
I'm maintaining some CGI web applications, which I'm migrating to a new Linux web server, on which I have a non-admin account, say www_maintainer. So I am installing the CGI applications inside /home/www_maintainer/, and I'd like to take the opportunity to clean things up, in particular the cgi-bin/ directory could be better organized; I'd like to learn about a best-practice standard for that.
For instance, is it normal to have subdirs called bin/ and lib/ inside cgi-bin/, with the binaries and libraries of auxiliary things?
I will describe a specific example, namely with the math- and data plot application gnuplot and its dependencies (libfontconfig, libpng , libgd, libjpeg, libreadline.so, ...).
Python could be another example (the distro provides 2.4 but I need >2.6), however I hope the admin can install 2.6 from a package so I don't have to worry about it.
The new web server has Scientific Linux (SL), which is based on Redhat RHEL. Unfortunately the distro repository for our current SL version does not provide gnuplot version 4.4 which I need, so it cannot be installed in the normal place like /usr/bin/, so I could build and install it and its dependencies in a non-system location, for example cgi-bin/tools/. The actual CGI web applications are binary executables launched by the scripts launch1.sh or launch2.sh.
Here is a illustration of the directory tree and some of the files in there (many dirs and files omitted of course).
cd /home/www_maintainer/www_root/
|-- html/
| |-- index.html
| `-- info.html
|-- cgi-bin/
| |-- gen/
| | |-- status.sh*
| | `-- sybase/
| | `-- DataAccess64/
| | `-- ODBC/
| | |-- lib/
| | |-- samples/
| | `-- spl/
| |-- exe1/
| | `-- launch1.sh*
| |-- exe2/
| | `-- launch2.sh*
| |-- javascript/
| | `-- check-input.js
| |-- scripts/
| | |-- decode.pl*
| | |-- generate-random-string.bash*
| | |-- gnuplot -> ../tools
| | `-- upload.php*
| |-- tools
| | |-- bin/
| | | |-- gnuplot*
| | | |-- python -> python2.6
| | | |-- python-config -> python2.6-config
| | | |-- python2.6*
| | | |-- python2.6-config*
| | | `-- xmlwf*
| | |-- etc
| | | `-- fonts/
| | |-- include/
| | |-- info/
| | |-- lib/
| | | |-- libfontconfig.so
| | | |-- libpdf.so
| | | |-- libreadline.so
| | | |-- libpng15.so
| | | |-- libpng15.so
| | | |-- pkgconfig/
| | | |-- libpng.so
| | | |-- libjpeg.so
| | | |-- libreadline.so
| | |-- libexec/
| | |-- man/
| | `-- share/
|-- tests/
| `-- results/
| `-- info/
| |-- readme.pdf
| `-- readme.html
|-- fonts/
|-- index.html -> html/index.html
|-- log/
| `-- log.txt
`-- tmp -> /tmp/
Would it be better to install outside the www_root, e.g.in the directory /home/www_maintainer/bin/ and /home/www_maintainer/lib/ and configure the web server to allow that?
EDIT: 05/23/2012 3pm PT US
If you're restricted to the user's directory, you can do pretty much whatever you want.
What used to be the common case was that you put all of the CGI-using files (Perl, etc) into the cgi-bin directory and you can (and probably should) put those in subdirectories based on the purpose or application.
Then you put the non-CGI files outside of the cgi-bin directory, which includes any bare HTML files, graphics files, CSS files, JS files, etc.
For any programs that are used by the CGI files but not directly by the web user, do not put them in the webroot at all as that is not necessary and could be a security hole if the web user can submit values into those programs in some fashion.
Directory tree example:
/home/www_maintainer/public_html/index.html
/home/www_maintainer/public_html/images/logo.png
/home/www_maintainer/public_html/scripts/something.js
/home/www_maintainer/public_html/cgi-bin/application1/app1.cgi
/home/www_maintainer/public_html/cgi-bin/application2/app2.cgi
/home/www_maintainer/public_html/cgi-bin/application2/app2helper.cgi
/home/www_maintainer/tools/gnuplot/gnuplot
/home/www_maintainer/tools/python/python -> python2.6
/home/www_maintainer/tools/python/python2.6
/home/www_maintainer/tools/python/python2.6-config
Then in your CGI files, make sure that the paths to the tools are set correctly as needed. It is not necessary for web users to access those tools directly, so keep those out of access. If you're doing python via CGI (which I assume, in this case), make sure your shebang line shows the correct path; #!/home/www_maintainer/tools/python/python, for example.
Original answer:
What a lot of applications do, such as the ones distributed with Debian, is put their applications in the /usr/share/lib/programname directory and then use an Apache Alias and ScriptAlias to map them to a base URL. This is how I used to run our own internally-developed applications as well and that worked very well.
For your situation, I'd recommend changing as little as possible unless you plan to enhance the code or the system more and more over time. Making changes could bring headache if paths change, especially if any are bookmarked, unless you want to get cozy with some mod_rewrite in your config.
Do you have any specific examples that I could use to demonstrate what I've described?
Also, with regard to ancient /usr/bin/python, is your system completely up-to-date? Or is the problem that your Linux distribution just doesn't push a newer version? I'd avoid installing a version of Python that isn't managed by your distro's package management system.