I'm creating a Homebrew formula for a C library that includes its own test suite. As part of the test block for the formula, I'd like to run the tests that are included with the downloaded files. The tests run as a make target (make test). However, Homebrew test blocks run in their own temporary directory and the downloaded files are not in the path. That is, the following doesn't work because it can't find the files:
test do
system "make", "test"
end
How can I access the location into which the files were originally downloaded and unpacked? I haven't been able to find any information about that in the docs. Or is there a better solution for Homebrew tests in this case?
The test do block is meant to test if a formula has correctly been installed, not to run test suits. If the tests don’t take too long you can run them as part of the install:
def install
# ...
system "make", "test"
# ...
end
To answer your question there’s no reliable way to get the original unpacked directory because it’s destroyed after install and the user may have deleted the cached tarball (with e.g. brew cleanup) so you’d have to re-download it.
A solution is to copy the necessary test files somewhere during the install step then use them directly or copy them in the current directory when testing, e.g.:
def install
# ...
libexec.install "tests"
end
test do
cp_r (libexec/"tests"), "."
cd "tests" do
# I’m assuming the Makefile's paths can be given
# as variables here.
system "make", "test", "LIB=#{lib}", "INCLUDE=#{include}"
end
end
Related
This question has been asked many time but I am not able to resolve the problem from them so I am asking
I had installed Cygwin a few days ago.I tried using ./configure command but it says
-bash: ./configure: No such file or directory
I tried using
where configure
but I got the output
INFO: Could not find files for the given pattern(s).
then I tried grep configureand I got this output
/etc/bash_completion.d/configure
/usr/i686-pc-cygwin/sys-root/usr/share/libtool/libltdl/configure
/usr/share/ELFIO/configure
/usr/share/libtool/libltdl/configure
I tried to export the path and then run the ./configure but it also didn't worked.
I find no executable file named as configure in my cygwin bin directory.
Does it mean that I have to add configure file manually?How can I correct it?
NOTE :- I had also tried sh configure but it also didn't worked
If a software project is set up to be built using autoconf, that tool generates a script canonically called configure. It queries the system for various parameters that are subsequently used in the build, and is specific to the software package to be built. Different software projects have different configure scripts. They are all called configure, but their contents are not the same.
So, to actually build such a software project once that script was set up (usually done by the maintainers when packaging the source tarball for distribution), you call:
tar xzf <tarball>.gz # or xjf <tarball>.bz2 or whatever
cd <sourcedir> # the one you just untarred
./configure
make
make install
Note the prefix ./, which means "located in this directory" (i.e. the top directory of that project's source tree).
Actually, the better procedure is the so-called "out-of-tree build", when you set up a different directory for the binaries to be built in, so the source tree remains unmodified:
tar xzf <tarball>.gz # or xjf <tarball>.bz2 or whatever
mkdir builddir
cd builddir
../<sourcedir>/configure
make
make install
So, there is supposed to be no configure executable in your PATH, you are supposed to call the script of that name from the source tree you are trying to build from.
If I correctly understood...
Configure is not an application that should be installed on your system, but script that should be delivered with source code to prepare for make command. File named configure should be in the main directory of source code.
I understand that this is an old question. However many might find this solution helpful.
Normally we use the make command to compile a downloaded source in cygwin. In many cases it contains a autogen.sh file. Running that file with
bash autogen.sh
will in many case solve the problem. At least it solved my issue and i could then use the make command
I'm configuring a CMake project from source and build and install it with make, i.e.,
$ ls
./build/ ./source/
$ cd build/
$ cmake ../source/
[...]
$ make
[...]
$ make install
[...]
I noticed now that the project is badly configured in that it contains numerous files with the same name that get overridden in the installation directory, e.g, /usr/local/include/mystring.h gets written to more than once by make install.
Is there a systematic way to detect if files are overridden within the same project?
Well, you can wrap install() calls into your own function, which would store all installed files in cache list variable and check for existing item before actually call install().
You may also check ${PROJECT_BINARY_DIR}/install_manifest.txt file - maybe it would contain duplicates in your case.
I'm having some trouble testing a command line gem in a TeamCity build environment.
I'm working on a gem for building various types of manifest files, elf_manifesto. It runs from the command line and I've successfully tested it with Cucumber, and the really useful Aruba gem. Locally I'm working on a Lion MBP, using RVM, ruby 1.9.2. Everything's hunky dory.
The problem's arisen when moving the build process to the TeamCity environment at work. The TeamCity agent is running on a windows box and the problem seems to be that when triggering the command line executable from Aruba the script isn't found in the path environment on the windows box. Here's a snippet of Cucumber output from the build log.
[13:46:37]: [Scenario: Start manifesto with no parameters] When I run `manifesto`
[13:46:37]: [When I run `manifesto`] ChildProcess::LaunchError: The system cannot find the file specified. (2)
The Aruba gem is meant to take care of adding the executable (which is in the bin dir) to the path when running the tests. This works fine on my local set up, but fails on Windows. I've tried adding a RUBYPATH environment variable to the build parameters in TeamCity, but so far no luck.
Does anyone have any pointers?
Thanks in advance.
In my experience, Aruba does not add your gem from bin/ into the path. Even on UNIX-based projects, I've had to do it myself:
In env.rb:
PROJECT_ROOT = File.join(File.dirname(__FILE__),'..','..')
ENV['PATH'] = "#{File.join(PROJECT_ROOT,'bin')}#{File::PATH_SEPARATOR}#{ENV['PATH']}"
That being said, I have never gotten Aruba to work on Windows the same way as it did on UNIX.
To help diagnose, make use of the #announce tag on your features (which causes stderr and stdout to be printed), and possibly even drop in your own log statements in your custom steps.
In Windows, only if file with some extension like .COM,.EXE (and others) is executable.
You can change manifesto to ruby manifesto like with correct path to manifesto, it should work on windows.
If you want to work in Unix platform also, you need to change in support\env.rb for Aruba like below
require 'aruba/cucumber'
module ArubaOverrides
def detect_ruby(cmd)
processor, platform, *rest = RUBY_PLATFORM.split("-")
#puts platform
if platform =~ /w32$/ && cmd =~ /^manifesto /
"ruby -I../../lib -S ../../bin/#{cmd}"
else
"#{cmd}"
end
end
end
World(ArubaOverrides)
Hope it helps
You should be aware that Aruba runs the application it tests and creates all local output in its own working directory (awd). The awd defaults to tmp/aruba and is purged and created by Aruba at the beginning of every Scenario. However, the contents created by the last Scenario are left in the awd for your inspection.
Solution #1
Aruba will automatically add the bin directory of your project to the PATH environment variable for the duration of each Cucumber scenario.
You can create a bin dir under your project root, and copy you binaries there
Solution #2
You can use aruba-jbb, which provide a #no-aruba-tmpdir tag to handle this case.
Goal
I am trying to create a port (Macports) for an open source tool based on Eclipse which doesn't need installation, in other words, it's just "extract and use" case. Users can download the tool from the official project site and use just like that. So there is no DESTROOT variable set.
Since many Mac users got used to the convenience of Macports, I would like to add the tool there, so that users could instantly install or uninstall the tool.
** Important notice: once users start the tool, it creates "/workspace" directory in the same place the tool was installed to keep users' preferences, settings, and other necessary files. So, when users starts the tool, the program should have access to write in the same directory it was installed. The current version of the tool doesn't provide a way to choose the workspace location.
Problem
How should I organize the Portfile?
I have set the following configurations where I tell Macports to not use configure, build, and destroot phases.
set cm_workspace /workspace
universal_variant no
use_configure no
supported_archs noarch
post-extract {
file mkdir ${worksrcpath}${cm_workspace}
destroot.keepdirs-append ${worksrcpath}${cm_workspace}
}
build {}
destroot {}
As I understand,
extract phase untars the file,
and install phases should archive those files,
and finally activate phase should move the files to the destroot.
But I keep getting errors.
---> Extracting cubridmanager
---> Configuring cubridmanager
---> Building cubridmanager
---> Staging cubridmanager into destroot
Error: No files have been installed in the destroot directory!
Error: Please make sure that this software supports 'make install DESTDIR=${destroot}' or implement an alternative destroot mechanism in the Portfile.
Error: Files might have been installed directly into your system, check before proceeding.
Error: Target org.macports.destroot returned: Staging cubridmanager into destroot failed
Log for cubridmanager is at: /opt/local/var/macports/logs/_Users_nbp_macports_databases_cubridmanager/cubridmanager/main.log
Error: Status 1 encountered during processing.
To report a bug, see <http://guide.macports.org/#project.tickets>
I want to contribute to that open source community, but I can't pass this step.
You misunderstood the phases, the usual workflow is as follows:
extract untars the downloaded file
patch applies any local patches
configure runs ./configure
build runs make
destroot runs make install DESTDIR=${destroot}
install packs the file in the destroot area into an archive
activate moves the files into ${prefix}
So, in your case, you don't need steps 2, 3 and 4. But you still need to copy the files to the destroot area in step 5, the destroot phase. Otherwise MacPorts does not know which files it is supposed to install.
supported_archs noarch
use_configure no
build {}
destroot {
copy ${worksrcpath} ${destroot}${prefix}/some/path
}
Note that MacPorts does discourage installing files outside the prefix directory, as the installation is meant to be self-contained. The path /workspace sounds like a pretty bad idea. Rather, you should use a path inside the users home directory to save any data as otherwise this cannot be used on a computer with multiple user accounts. Of course, the actual executable files can reside in the MacPorts prefix.
Normally, UNIX software separates binaries, libraries and shared data in /usr (or in the MacPorts case,/opt/local) from user-specific data in the home directory. If your tool does not follow this convention, this needs to be fixed by the developers first.
I don't think that tool fits with macports for related reasons
All files from macports should be in one of the supported directories i.e. destroot and ending up in /opt/local
The project tries to write to sub directories which is not good here
The directories written to bu macports can only be written to by the user macports so as to minimize the ability to affect the build and run environment.
In a multiuser system who owns the directory to write to? e.g. macports are installed as user macports and are run as someone else - Also if there are more than one normal user who writes to the directory?
I think you need to patch the tool so that it is passed a directory to create the workspace in when a normal user runs it but the tool is install as ownwd by macports in /opt/local/bin
I'm creating a Linux tgz self-extracting installer using CPack and I'd like the installer to run a script or sequence of commands after all files have been installed. CPack documentation contains the following guidance:
CPACK_INSTALL_COMMANDS Extra commands to install components.
I set this variable in my CMakeLists.txt file and I see it set in the resulting CPackConfig.cmake file, but the commands I embed in this variable do not appear anywhere in the final .sh install script. What am I missing?
You're not missing anything, that's simply not how the CPACK_INSTALL_COMMANDS variable works.
On a typical project, CPack does a "make install" into a temporary location, in order to build the final installer based on the "make install" tree. The CPACK_INSTALL_COMMANDS variable is meant to be set for projects that would rather run some other command sequence, instead of the typical "make install" in order to produce the install tree.
So, CPack should be running your commands as it generates the package. It will not run your commands on the end user's machine at the end of him/her running the generated installation script...
There are per-generator ways of running installed executables and/or scripts at the end of the end user installation, but it will require some customization on your part. In this case, I'd recommend attempting to override the CPack.STGZ_Header.sh.in input file that is used when CPack generates the STGZ self-extracting script. Customize that file and add your calls to the bottom of it, above the line:
exit 0
To override the file, provide your own copy of it in your source tree, perhaps in a ${CMAKE_CURRENT_SOURCE_DIR}/CMake directory, and then in your CMakeLists.txt file, add:
set(CMAKE_MODULE_PATH ${CMAKE_CURRENT_SOURCE_DIR}/CMake ${CMAKE_MODULE_PATH})
(Actually, as I'm writing this, I'm wondering if that's sufficient, or if the module path also needs to be set at the time that CPack runs... Try this, and let us know if your customization gets used by CPack or not. If not, I'll investigate a bit further and add some more advice here.)