How can I make ExtUtils::Manifest include empty directories? - perl

I am trying to build a Perl module for distribution. The directory structure looks like this:
demo
demo/files
demo/examples/example1.pl
demo/scripts
lib
I used this command to generate the MANIFEST file:
perl -e "use ExtUtils::Manifest qw(mkmanifest); mkmanifest();"
The file is created but all of the empty folders are ignored, so demo/files and demo/scripts are not in the MANIFEST.
How can I tell ExtUtils::Manifest to include empty folders?

Create a zero byte file called .exists in the otherwise empty directories.

Related

bitbake BBPATH confusion

In the bitbake manual (https://www.yoctoproject.org/docs/1.6/bitbake-user-manual/bitbake-user-manual.html) it says:
3.3.1. Locating Include and Class Files
BitBake uses the BBPATH variable to locate needed include and class files. The BBPATH variable is analogous to the environment variable PATH.
3.3.3. include Directive
BitBake understands the include directive. This directive causes BitBake to parse whatever file you specify, and to insert that file at that location. The directive is much like its equivalent in Make except that if the path specified on the include line is a relative path, BitBake locates the first file it can find within BBPATH.
As an example, suppose you needed a recipe to include some self-test definitions:
include test_defs.inc
However, I see many openembedded-core recipes that include files that seem to be relative to the file they are being included from rather than being in a directory in BBPATH, i.e.
Assume we have this directory structure:
mything.bb
mything.inc
include/mything.inc
And mything.bb contains:
require mything.inc
require include/mything2.inc
However, these files are not in the BBPATH. I run bitbake -e mything.bb and BBPATH clearly does not contain the directory containing mything.inc or include/mything2.inc.
So the question is, is it true that include/require directives first search for the file relative to the file the directive appears in? Then and the falls back to searching for it in the BBPATH? If so, is this feature just missing from the bitbake user manual documentation?

Can I have multiple configure.ac files and what to do with AC_OUTPUT then?

I have this directory structure:
foo
foo/libfoo - libfoo project
foo/libfoo/src - sources
foo/foo - foo project
foo/foo/src - sources
There are two separate things that have to be build here, a libtool library (libfoo) and an executable (foo) using that library.
I could just place a configure.ac file into each foo/libfoo and foo/foo and everything would be fine.
However I would like to be able to build both projects at once, so I thought about placing an additional configure.ac into the top level foo directory.
Is this a good idea?
If yes, how would the AC_OUTPUT makro be used in such a case?
Does the top level configure.ac file generate all the Makefiles in the whole tree or are there separate AC_OUTPUT makros in the sub directories that each output there Makefiles?
Since both projects have different dependencies I would think the subdir ac files do the output of their makefiles?
Can the two projects in the sub dirs still be build separately in this case?
There is a AC_CONFIG_SUBDIRS macro that does what I want, it recurses into subdirs and executes the configure.ac files there.
The sub dir projects can still be build independently.
My Makefile.am only contains SUBDIRS = libfoo foo now.
The configure.ac file contains AC_CONFIG_SUBDIRS=([libfoo foo]).

Using CMake to index source files of an external library with Eclipse

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.

lattice-tool path issue

I have downloaded and installed a perl tool (lattice-tool).
But it is in my local directory.
While I'm running it says can't locate Directed.pm(a lib file) which is available in lib folder of my local directory.
I hope it will be set right if I set path variable. If so, how do I set it?
For use lib you have to use full path, and you are should not use relativ path like this.
use '../lib';#not working in all times.
Scenario: Your scripts in something/bin/prog.pl, your lib is something/lib/lib.pm.
If you use relativ path, you should call your program like this:
cd something/bin/ && ./prog.pl
If you would like to use relativ path, use FindBin to find your current path:
use FindBin;
use lib "$FindBin::Bin/../lib";#your lib realitv to your script
use lib $FindBin::Bin;#your current script full path
Then you could call your program from anywhere it will always find its lib realtiv to itself.
cd ~
something/bin/prog.pl# ti will use the correct lib
In my scripts, I have the following (which I'm sure can be improved, but it has worked thus far):
my $mydir; BEGIN { ($mydir) = ($0 =~ m#(.*)[/\\]#) or $mydir = '.'; }
use lib "$mydir/lib";
So the script tries to determine its own directory and then tells Perl to look for libraries within the lib subdirectory of that directory.
You need to add 'lib' to the directories perl searches for modules. You can do this with the -I flag:
perl -Ilib lattice-tool.pl
Use lib:
use lib 'lib';
lib also checks for architecture specific sub directories under lib to make sure machine-dependent libraries are loaded.
EDIT: Note that directories passed to lib are relative to your current working directory, so that if you want to execute your script from another location you should use use lib '/home/user1126070/lib'.
From perlvar:
The array #INC contains the list of places that the do EXPR , require, or use
constructs look for their library files. It initially consists of the arguments
to any -I command-line switches, followed by the default Perl library, probably
/usr/local/lib/perl, followed by ".", to represent the current directory. ("."
will not be appended if taint checks are enabled, either by -T or by -t .) If you
need to modify this at runtime, you should use the use lib pragma to get the
machine-dependent library properly loaded [...]

R CMD check complains about unexpected files in man

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.