I am looking for modules inside an intellij Project for Kotlin.
My structure is like that:
|- Project
|-- .idea
|-- src
|-- Project.iml
And i want to have a Module inside the project like:
|- Project
|-- Module1
|---Project.iml
|-- .idea
|-- src
|-- Project.iml
The module was created by right clicking on the project in the project structure view and creating a new module. There I couldnt find an option for Kotlin, only for java.
I tried Java, but I get the Error, that it can't find Kotlin functions like println(), understandable.
So are there Kotlin Submodules?
Kotlin code runs normally inside the project.
It's a known limitation.
There is no way to add Kotlin modules at the moment.
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 am trying to use splint on moderately large project which uses cmake for build.
Project contains hundreds of source file scattered over large directory structure. I am not finding any info for using splint with cmake.
directory structure is like
|-- CMakeLists.txt
|-- dir1
|-- CMakeLists.txt
|-- src
'-- file1.c
|-- include
'-- file1.h
|-- dir2
|-- CMakeLists.txt
|-- src
'-- file2.c
|-- include
'-- file2.h
Thanks.
Let me Google it for you. For "cmake splint" Google gives this link as 2nd result.
You can use it in your project if license permits, or just use it as reference when writing your own module. It is very simple, all it does is call splint executable with needed flags on requested sources using cmake's add_custom_target command.
I have a directory layout like the following
projectA/
|-- CMakeLists.txt
|-- src/
|-- main.cpp
projectB/
|-- CMakeLists.txt
|-- src/
|-- file1.cpp
|-- file1.hpp
|-- file2.hpp
|-- main.cpp
|-- third_party/
|-- include
|-- lib1
I can build my code (separately) for projectA and projectB just fine, i.e. both projects run by itself, independet of each other.
Now, in projectA I need to use code that exists in projectB (specifically file1.cpp, file1.hpp, file2.hpp and the third party libs).
It seems bad practice to me to just copy the necessary files from projectB/src, paste it into the src directory of projectA and adjust the CMakeLists.txt in projectA accordingly (by partially merging projectB/CMakeLists.txt and projectA/CMakeLists.txt).
Is there a nice way I can use CMake to (and now I'm not sure about the right terminology) include the project defined by projectB/CMakeLists.txt in projectA/CMakeLists.txt. The idea is that everything concerning projectB to run independently is stated in projectB/CMakeLists.txt and shouldn't I be able to access this information when I want to use it in projectA?
This is probably a common question, nevertheless I did not find anything helpful online, might also be due to not having the right terminology at hand.
You have to decide the level of encapsulation you need.
Package: If dependency ProjectB can run independently and you only ever need it for its compiled library, then use CMake's packaging system, i.e. export(TARGETS) or export(EXPORT) or export(PACKAGE) or install(EXPORT).
add_subdirectory: If dependency ProjectB also has build target information you need, e.g. compile defines, flags and other dependencies, then you can just make a top-level CMakeLists and use add_subdirectory()
include: If dependency ProjectB only has sub-target properties you need, including sources, you could include() the CMakeLists.txt, but this is really designed for sub directories and where you do not want to change the existing current directory for CMake processing
Interface library: If your third party libraries are not header-only, then they should probably be independent packages, otherwise assuming they are not huge like Boost, you can just copy them to ProjectA. Boost-like dependencies should almost always be kept external to projects
Hardcode paths: You could hardcode paths to the individual files of projectB, but this is brittle without making it a subdirectory of projectA, which in turn would offer better solutions, as above
Refactor to third library: If none of the above fits, you could refactor out the specific files as a separate library and use the standard packaging mechanism to depend on it for both ProjectA and ProjectB.
You can use ExternalProject module
https://cmake.org/cmake/help/v3.7/module/ExternalProject.html
Suppose, projectB is library. Then:
project("A")
include(ExternalProject)
ExternalProject_Add(b_lib
SOURCE_DIR "${B_SOURCE_DIR}"
BINARY_DIR "${B_BUILD_DIR}"
CMAKE_ARGS "-DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}"
"-DCMAKE_INSTALL_PREFIX=${B_INSTALL_DIR}"
"-DARBITRARY_VAR=some_value")
add_executable(a_exe src/main.cpp)
target_include_directories(a_exe PRIVATE "${B_INSTALL_DIR}")
target_link_libraries(a_exe "${B_INSTALL_DIR}/b_lib")
I have a simple project with one shared library called A and one executable called B linking A. I make a Visual Studio 2017 build just outside my sources so that the build directory and the source directory have both the same parent directory. This is fine.
But when I build my Visual Studio 2017 solution, many undesired directories appear under parent directory as well; one for each target that did run (A, B, INSTALL, etc.) that contains the build log for that target. I don't want those polluting log directories or it would be OK if they would appear under my build directory along Visual Studio 2017 stuff if they can't be avoided. Anyone knows how to handle this?
CMake version: 3.8.1
EDIT
The last 3 directories are those that are unwanted:
Parent directory
|-- build-vc15-x64 directory
|-- VS 2017 related stuff
|-- sources directory
|-- CMakeLists.txt
|-- libA sources directory
|-- stuff for libA
|-- execB sources directory
|-- stuff for execB
|-- unexpected directory here when building libA in solution in build-vc15-x64 (contains build log file of libA)
|-- unexpected directory here when building execB in solution in build-vc-15-x64 (contains build log file of execB)
|-- x64 (contains build log file of target INSTALL)
Use out-of-source builds, in other words, your build and your source directory should be different directories. Additionally, you have to call CMake and build just within your build directory, not in the parent directory. CMake creates a bunch of auxiliary files and directory right where it is called.
There is no point calling CMake in the common parent directory of source and build dir.
I am trying to develop an llvm pass under my project directory. For that, I follow the info in http://llvm.org/docs/CMake.html#developing-llvm-pass-out-of-source. I create my CMakeFiles appropriately as in this link and my final project directory is like;
|-- src
| |-- CMakeLists.txt
| |-- bigForPass
| | |-- CMakeLists.txt
| | |-- bigForPass.cpp
| | |-- merged.bc
| |-- build
I also linked my source files with llvm root directory without any problem.
Finally I make the build under the 'build' folder and my shared library is created successfully with no problems (under build/bin folder) with the name LLVMHello1.dylib.
However, when I try to run my pass over merged.bc file (which contains my llvm code) with the command
opt -load ../build/bin/LLVMHello1.dylib -bishe_insert <merged.bc> final.bc
I keep getting the error;
Error opening '../build/bin/LLVMHello1.dylib': dlopen(../build/bin/LLVMHello1.dylib, 9): Symbol not found: __ZTIN4llvm10ModulePassE
Referenced from: ../build/bin/LLVMHello1.dylib
Expected in: flat namespace
in ../build/bin/LLVMHello1.dylib
-load request ignored.
Any ideas and suggestions on this appreciated ?
Thanks a lot in advance.
from http://www.jiang925.com/node/28
Undefined Symbol: _ZTIN4llvm12FunctionPassE There is an inconsistency
between LLVM main build system and the cmake support for building
out-of-source. The LLVM binaries are built without runtime type info
"-fno-rtti". Therefore, the out-of-source passes have to be built the
same way otherwise opt will complain that symbol
"_ZTIN4llvm12FunctionPassE" is undefined.
To solve this problem, LLVM must be compile with RTTI enabled. Add
"-DLLVM_REQUIRES_RTTI=1" to cmake, or add "REQUIRES_RTTI=1" to make.
So I added SET(CMAKE_CXX_FLAGS "-Wall -fno-rtti") to CMakeLists.txt of my pass library and then it's working.