I have a data folder which contains a script which is only needed during development preparing some data.
|--mypackage
|--mypackage/data
|--mypackage/data/prepare.py
The problem is that this py file is included in the package. I tried to exclude it with:
[tool.setuptools.packages.find]
where = ["."]
exclude = ["mypackage*data*py"]
But this does not seem the correct syntax. Or maybe it is not supported to exclude py files?
Related
I can't use functions of custom subdirectories.
My Code Organziation
I have under "src" a path hierarchy like
a/b
with all my directories and go-Files (it is the "root" of my project). The directories contain no subdirectories and it works fine. So the deepest path is "a/b/c". E.g. I have
a/b/c
and
a/b/d
with some go-files. Import of "a/b/d" and calling a function with "d.DoSomething()" from a file in "a/b/c" works fine.
Problem description
Now I want ot reorganize "a/b/d". I move some files from "a/b/d" to
a/b/d/e
and the rest of the files to
a/b/d/f
If try to import "a/b/d/e" with import-statement
import ( "a/b/d/e" )
from the same file in "/a/b/c" and want to call "e.DoSomething()" (it is the place, where the file with the "DoSomething-function" moved to), I get an error at the line, where I call "e.DoSomething()": "undefined: e".
While searching for a result, I've nowhere seen examples with deeper path hierarchies. Is it generally not possible to use/import subdirectories or what's the problem?
go-version I used: go1.2.2 linux/amd64
Thanks for any advices
Your approach is completely wrong. Go has absolutely no concept of importing files or directories, all you can import in Go are packages. It now happens that the name of a package is it's path relative to GOPATH and you import packages by that name. But the identifier under which an imported package is available in the importing code depends on the package declaration of the package. You cannot simply "move" files between directories as each directory (for the go tool) is a single package without changing the package declaration.
You can have package x under path a/b/c. When you import package x with import ( "a/b/c" ) all the exported stuff from package x is available to you as x.ExportedName.
Please read http://blog.golang.org/organizing-go-code carefully.
Try and do a go build in a/b/d/e first, before trying to build in a/b: that will generate the compiled classes you want to import.
I have a Pydev/Eclipse project with a src/ directory and a data/ directory. Is there an easy way to access the full path of data/ (and the files there) from within a Python script (in src) without specifying the full data path explicitely?
You could do
import os
print os.getcwd()
and then just remove the /src/ part and add /data/. It would technically be the full path but It would be working using the assumption that src and data are int the same top folder.
[Edit]
Something like this (if you are on *nix)
import os
path = os.getcwd()
split_path = path.split('/')
new_path = ''.join([s + '/' for s in split_path[:-1]])
new_path += 'data/'
Guess it will be similar on Windows
I am using CMake to build a project with external libraries by using "Eclipse CDT4 - Unix Makefiles".
Importing in Eclipse leads to a working project, but only all header files and my implemented source files are recognized correctly by the index of Eclipse.
I would also like to navigate through the source files for one external library by using "ctrl+click". I don't know how to add the *.cpp files of that external library in my CMakeList.txt to get them recognized by the indexer without building the library.
You can mark the .cpp files as "header file only" like this:
# find all filenames in the lib path and gather them in $YOUR_LIB
FILE(GLOB YOUR_LIB path_to_library/*.?pp)
# create a seperate sourcegroup so it doesn't clutter up the rest of your code
SOURCE_GROUP(\\lib FILES ${YOUR_LIB})
# mark them as header-file only
SET_SOURCE_FILES_PROPERTIES(${YOUR_LIB} PROPERTIES HEADER_FILE_ONLY TRUE)
# add both your code and the lib-code to the project
ADD_EXECUTABLE(program ${YOUR_CODE} ${YOUR_LIB})
I found a way to attach external library source files to the Eclipse project that is compatible with CMake project generator.
It turns out that to indexing and "ctrl+click" navigation works correctly only when external library sources are direct descendants of the project source folder. Therefore the solution is following:
Scan external library folder for source files.
Create a child folder under project's source folder.
Symlink discovered sources inside the created folder.
I created a CMake function attachExternalSources that performs above steps:
function(attachExternalSources librarySourceLocation folderName)
# Create folder for Geant4 sources
file(MAKE_DIRECTORY ${CMAKE_SOURCE_DIR}/${folderName})
message(STATUS "Searching for C++ sources in \"${librarySourceLocation}\"...")
FILE(GLOB_RECURSE libSources
${librarySourceLocation}/*.c
${librarySourceLocation}/*.cpp
${librarySourceLocation}/*.cxx
${librarySourceLocation}/*.cc
)
message(STATUS "Symlinking sources into\n \"${CMAKE_SOURCE_DIR}/${folderName}\"\n Please wait...")
foreach(source ${libSources})
# Obtain source filename
get_filename_component(source_filename ${source} NAME)
# Create symlink unless it already exists
set(symlink "${CMAKE_SOURCE_DIR}/${folderName}/${source_filename}")
if(NOT EXISTS ${symlink})
execute_process(COMMAND ${CMAKE_COMMAND} -E create_symlink ${source} ${symlink})
endif()
endforeach()
# Scan all the symlinks created under the project folder and disable their compilation
FILE(GLOB sources_symlinks ${CMAKE_SOURCE_DIR}/${folderName}/*)
SET_SOURCE_FILES_PROPERTIES(${sources_symlinks} PROPERTIES HEADER_FILE_ONLY TRUE)
endfunction()
The use of the function is following. Paste above function code in your CMakeLists.txt. Next, use it as follows:
attachExternalSources("path/to/external/library/sources" "library-sources")
First parameter is location of the external library source code. Second argument is the name of a folder inside your project that that will contain source symlinks.
P.S. I tested function with Eclipse 4.19 and CMake 3.20.5.
I recently decided to use SBT to build an existing project.
In this project I have some .glsl files within the scala packages which I need to copy during the compilation phase.
The project is structured like this :
- myapp.opengl
- Shader.scala
- myapp.opengl.shaders
- vertex_shader.glsl
- fragment_shader.glsl
Is this file structure correct for SBT or do I need to put the .glsl files into an other directory. And do you know a clean way to copy these files into the target folder ?
I would prefer not putting these files into the resources directory since they are (non-compiled) sources files
Thanks
I would not recommend putting those files into src/main/scala as they do not belong there. If you want to keep them separate from your resource files, you can put them in a custom path, e.g. src/main/glsl and add the following lines to your project definition to have them copied into output directory:
val shaderSourcePath = "src"/"main"/"glsl"
// use shaderSourcePath as root path, so directory structure is
// correctly preserved (relative to the source path)
def shaderSources = (shaderSourcePath ##) ** "*.glsl"
override def mainResources = super.mainResources +++ shaderSources
this sounds like a silly problem: I'm putting my R code into a package and R CMD check src complains about the .Rd~ backup files being produced by Emacs.
* checking package subdirectories ... WARNING
Subdirectory 'man' contains invalid file names:
read.PI.Rd~ write.PI.Rd~
the documentation says: »In addition [...] files [...] with base names [...] ending in ‘~’, ‘.bak’ or ‘.swp’, are excluded by default.« (page 18). but then why the warning?
Just add a file cleanup which removes them in your top-level directory. Also, you could build a tarball or zip archive first via R CMD build and the check this archive via R CMD check -- that should skip these filese as well.
Also, exactly how are you calling R CMD check, and what is your directory layout? With R 2.10.0 on Linux, I just ran touch pkg/man/foo.Rd~ for one of my packages, and R CMD check pkg (where pkg is the top-level directory as common for source projects stored on R-Forge)
did not issue this warning you are seeing. The file was not removed by cleanup as that currently purges only in src.