Boost.Filesystem-like Library for D - iterator

Has anybody written a D library similar to Boost.Filesystem providing iterators/ranges that can do for example file system directory tree traversal?

dirEntries from std.file returns a range that enumerates files and directories, optionally under subdirectories as well.

Related

CMakeLists using variables to define source/include locations

I have an AndroidStudio project with 'C' files in. I can compile and run as-is.
My native files are in
src/main/jni/aes
src/main/jni/libjpeg
src/main/jni/smuglib
I am trying to move the source to a location external to the Android studio project so that I can use it from several locations/projects to avoid copy/paste/mistake cycle.
I have defined the include path in CMakeLists.txt
include_directories(src/main/jni/aes src/main/jni/libjpeg src/main/jni/smuglib)
And have specified the files in the add_library command
add_library( # Sets the name of the library.
native-lib
# Sets the library as a shared library.
SHARED
# Provides a relative path to your source file(s).
src/main/jni/aes/aes.c
src/main/jni/smuglib/smuglib.c
.... etc
How do I set up a variable to refer to these paths, eg 'src/main/jni/aes' so that I can use it in both the include and in the source list?
I tried variations on
set(aes_src, src/main/jni/aes)
but uses of it as ${aes_src} either in the include path statement or in the source list give me all sorts of arcane errors which I am at a loss to understand.
I will generate some of these and include them if folk think it would help, but I am likely barking up the wrong kettle of fish with this approach.
Is there a better approach?
It is set(VAR_NAME item1 item2 item3). No commas needed.

Build Complex Project Filter via CMake

I built a C++ project which the file structure as same as the image
Every Cpp file is an isolated executable file. And I would like to build a project filter as same as the file structure via CMake.
The following code sample shows the root CMakeLists.txt I wrote for this purpose:
project(Samples)
source_group( "Samples\\ClientSamples" FILES ${PROJECT_SOURCE_DIR}/ClientSamples/ClientSamplesMain.cpp )
source_group( "Samples\\GenericSamples" FILES ${PROJECT_SOURCE_DIR}/GenericSamples/GenericSamplesMain.cpp )
source_group( "Samples\\ServerSamples" FILES ${PROJECT_SOURCE_DIR}/ServerSamples/ServerSamplesDemo.cpp ${PROJECT_SOURCE_DIR}/ServerSamples/HttpServerSample.cpp )
add_subdirectory(GenericSamples)
add_subdirectory(ServerSamples)
add_subdirectory(ClientSamples)
And the result didn't match my expectation.
The result is
.
So, is there a way to reach the goal?
Best Regards.

find_library chooses the static library instead of the shared library

This has been asked on SO before and there's even a related bug on this in CMAKE. However, my issue is a variation and the answer is not clear.
My wrinkle is that I'm cross-compiling for Windows on Linux using MinGW. Static libs are named like this libGLESv2.dll.a and libiconv.dll.a for the DLLs libGLESv2.dll and iconv.dll respectively.
Examples:
find_library(FOUND_LIB_X NAMES "zlib1.dll" PATHS ${CMAKE_FIND_ROOT_PATH}/bin/)
finds this: zlib1.dll
find_library(FOUND_LIB_Y NAMES "libGLESv2.dll" PATHS ${CMAKE_FIND_ROOT_PATH}/bin/)
finds this: libGLESv2.dll.a
find_library(FOUND_LIB_Y NAMES "iconv.dll" PATHS ${CMAKE_FIND_ROOT_PATH}/bin/)
finds this: libiconv.dll.a
The CMAKE bug seems to be referring to traditional situations where the static lib is named blah.lib (Windows) or blah.a (Linux). In this cross-compiler situation with mingw on Linux, they are named blah.dll.a
I need it to find the file literally called iconv.dll and nothing else. If it doesn't literally find that, then abort. Am I using the wrong CMAKE function? (don't use find_library()?)
CMake uses definite order between iterating library names and directories when search the library. E.g., according to documentation,
When more than one value is given to the NAMES option this command by default will consider one name at a time and search every directory for it.
That is, with libraries at dir1/name2 and dir2/name1
find_library(MYLIB NAMES name1 name2 PATHS dir1 dir2)
message(${MYLIB})
will print dir2/name1.
Specifying NAMES_PER_DIR option reverse the choice:
find_library(MYLIB NAMES name1 name2 NAMES_PER_DIR PATHS dir1 dir2)
message(${MYLIB})
will print dir1/name2.
Things are different with trying library's prefix and suffix:
Each library name given to the NAMES option is first considered as a library file name and then considered with platform-specific prefixes (e.g. lib) and suffixes (e.g. .so).
It seems that checking for lib<name>.so is performed immediately after <name> when iterating directories.
That is, with libraries at dir1/libname.so and dir2/name
find_library(MYLIB NAMES name PATHS dir1 dir2)
message(${MYLIB})
will print dir1/libname.so.
That is why libiconv.dll.a is found in your case: lib/ directory is searched as system specific path at step 5 of find_library search algorithm, but directory bin/, specified as PATH option, is searched only at step 6.
The simplest way to find what you want is to use NO_DEFAULT_PATH option, so searching in lib/ will not be performed at all:
find_library(FOUND_LIB_Y
NAMES "iconv.dll"
PATHS ${CMAKE_FIND_ROOT_PATH}/bin/
NO_DEFAULT_PATH
)

With CMake, how can I use the same source for a library for multiple different builds

I'd need to find how to best use CMake to build multiple different versions of the same library.
Let's assume that I have software A, B and C. All of these use the same external library, let's call that D. Let's assume that D is huge compared to A, B & C. So just using svn:external to checkout it multiple times is a bad option.
What crossed my mind is to have a folder where I have the subfolders for A, B, C & D and just calling add_subdir(../D). But to make things complicated, I don't want to enforce this folder structure on other developers, so I ended up with the thought of making this work with find_package, somehow.
What I'd like to see is that you are able to get C and D from subversion to any folders and have C compile it's own version of D for itself and use it, with no effort from the custom folders.
This might seem like a silly dream, but not being the smartest man on the planet, maybe someone has an idea of how to achieve this.
EDIT:
note that A B & C cannot use the same binaries for D since they would use different compiler flags to build the library.
add_subdirectory works with directories located outside the main project dir, you just have to give a binary_dir.
add_subdirectory(source_dir [binary_dir] [EXCLUDE_FROM_ALL])
Add a subdirectory to the build. The source_dir specifies the directory in which the source CMakeLists.txt and code files are located. If it is a relative path it will be evaluated with respect to the current directory (the typical usage), but it may also be an absolute path. The binary_dir specifies the directory in which to place the output files. If it is a relative path it will be evaluated with respect to the current output directory, but it may also be an absolute path.
In A, B and C you could have something like that:
set(MYPROJECT_D_PATH "" CACHE PATH "Path to D")
if("${test}" STREQUAL "")
message(FATAL_ERROR "You must set MYPROJECT_D_PATH")
endif()
add_subdirectory(${MYPROJECT_D_PATH} D)
When you compile A, B or C for the first time, you provides the path to D like that:
cmake <src_dir> -DMYPROJECT_D_PATH=<path_to_D>

importing files from other directories in xcode

I have the following directory structure.
A
|---B
| |---C
| |---D
|
|
|---E
| |---F
| |---G
I have A directory under which I have B and E. In B, I have C and D files and in E I have F and G files.
I am working on G file and I need to import D file. How do I do that ? If I directly write import "G.h" its throwing error as it will search in E folder. If I use import , its throwing error. Please let me know how to traverse directories in Xcode. I am using latest version of XCode (Xcode 4.6). Thanks!
If you have added the files to the project correctly you should simply be able to write
#import "G.h"
as the physical location should not be an issue. Xcode should be keeping track of those.
Try removing and re-adding the files in question.
You could add "B" to the "Header Search Paths" directly in the Project or Target Build Settings.
Add "${SRCROOT}" to HEADER_SEARCH_PATHS to include your source directory. In your Example it points to A.
If you set it to recursive it will check all subfolders (including B).
With "${SRCROOT}/B" you would only include the header files in folder B.
The quotes are needed, if you have blank space in the path.
But you should not need to do that, if the desired file (G.h) is in you xcode-project.
Try re-adding the file as suggested by Mundi.
Apple Developer Documentation: SRCROOT