I wanted to install some info document of libavl. I found some weird behavior of brew command with the following brew library that I made. What I did were:
First, I compile it with "make libavl.info."
Second, I created share/info under brew KEG PREFIX.
Third, I installed some info files to that share/info.
I do not know yet how I can symbolic-link those info files in system directory such as "/usr/local/share/info", but I want to have this brew formula. To make sure before and after installing info files that I have those info files in the corresponding KEG PREFIX, I printed directory structure in a file called "log," which is also installed to the KEG PREFIX. But, those info files disappeared after the installation. I do not know what happened. I do not know where I should ask in the homebrew website Brew.sh, so I ask this question here.
THIS IS THE FORMULA FILE called "avl.rb"
require 'formula'
class Avl < Formula
homepage 'http://savannah.gnu.org/projects/avl'
url 'ftp://ftp.gnu.org/pub/gnu/avl/avl-2.0.3.tar.gz'
sha1 'ec2e025838c846fbc05fb60cf49035f2e97f37f3'
def install
system "make", "libavl.info"
info.mkpath
system "/usr/local/bin/tree " "#{prefix} > #{prefix}/log"
info.install "libavl.info"
info.install "libavl.info-1"
info.install "libavl.info-2"
info.install "libavl.info-3"
info.install "libavl.info-4"
system "/usr/local/bin/tree " "#{prefix} >> #{prefix}/log"
end
end
The "log" file content before info.install command in the brew formula:
/usr/local/Cellar/avl/2.0.3
├── log
└── share
└── info
2 directories, 1 file
This is the content of "log" file after info.install command:
/usr/local/Cellar/avl/2.0.3
├── log
└── share
└── info
├── libavl.info
├── libavl.info-1
├── libavl.info-2
├── libavl.info-3
└── libavl.info-4
2 directories, 6 files
This is the final installed KEG PREFIX directory. There is the "log" file, but no "share/info" directory in it.
/usr/local/Cellar/avl/2.0.3
├── AUTHORS
├── COPYING
├── ChangeLog
├── INSTALL_RECEIPT.json
├── NEWS
├── README
├── TODO
└── log
0 directories, 8 files
I will appreciate any answers to this mystery.
Thank you,
Homebrew does not install info files by default. You can change this by setting HOMEBREW_KEEP_INFO=1.
Related
I have the following project structure, outside of GOPATH.
. // Project root
├── Dockerfile
├── .env
├── README.md
└── src
├── main.go
├── go.mod
├── go.sum
├── internal
│ ├── somepackage
│ │ ├── main.go
│ │ └── types.go
│ ├── someother
│ │ ├── main.go
│ │ ├── oauth.go
│ │ └── types.go
│ └── models
│ └── main.go
└── pkg
├── somepackage
│ └── main.go
└── anotherpackage
└── main.go
I want to run my Go module code located in the src directory.
When I cd into the src directory and go run . or go build . my code, it works perfectly.
When I stand at the root of my project, I am unable to run go run ./src or go build ./src. I get the following error.
src/service.go:8:2: cannot find package "web-service/internal/auth" in any of:
/usr/lib/go/src/web-service/internal/auth (from $GOROOT)
/home/miloertas/Packages/go/src/web-service/internal/auth (from $GOPATH)
src/endpoints.go:3:8: cannot find package "web-service/internal/handlers" in any of:
/usr/lib/go/src/web-service/internal/handlers (from $GOROOT)
/home/miloertas/Packages/go/src/web-service/internal/handlers (from $GOPATH)
It's important that my source code remains in this src directory.
It is equally important that I am able to run and build my code from the root of my project (For example the .env file is located at the root of the repository).
I am therefore looking for a way to run or build my code in the src directory from the root of my project.
I tried moving the go.mod at the root of the project and running and ran go run ./src but this causes issues of its own:
The go command is now unable to locate all the sub-packages in internal and pkg
VSCode is now lost and executing tests is impossible for some reasons (Mainly because all sub-packages are not found).
Since Go 1.18, it's now possible to achieve this with Go workspaces.
Using the following directory structure
parent-dir/
└─ go.work
hello-world/
├─ go.mod
└─ main.go
You can run the hello-world module from the parent-dir using go run hello-world.
go.work
go 1.18
use ./hello-world
go.mod
module hello-world
go 1.18
Note: it is possible, not recommended as pointed out by #Volker
It's important that my source code remains in this src directory. It is equally important that I am able to run and build my code from the root of my project (For example the .env file is located at the root of the repository).
These two requirements are contradictory. You have to let go of one.
Especially the second one is unfounded: Do not use go run, use go build. Make the path to look for the .env file a command line option to your program (Go is not PHP or JavaScript, there simply is no project or source root for the executing binary). Or build the executable somewhere but execute it in you project root.
Note that having a src folder is -- to put it mildly -- uncommon.
I tried moving the go.mod at the root of the project and running and ran go run ./src but this causes issues of its own:
Well, start by not using go run at all, use go build. And then try building the actual main package. All the go tooling works best on packages, not on file system folders. If your module is named playing.hardball/for-unspecific-reasons and package main is in src try go build playing.hardball/for-unspecific-reasons/src.
Takeaways even if this doesn't work out the way you want:
Do not use go run. The reasons are manyfold, it is useful to run single file scripts and a loaded footgun for basically every other use case.
The go tool works on import paths. In simple cases the import path can be inferred from the filesystem.
A compiled executable has no notion of a "project directory", "source", "classpath" or whatever, it is a standalone executable runnable everywhere and completely detached from its sources.
Make all filesystem lookup path a configuration option (cmdline flag or environment variable); provide practical defaults (e.g. ./); use that when running your executable to announce where to find static stuff like .env files, templates, icons, css files, etc.
I am on mac and Installed maven using the brew install maven command. The maven was installed in /usr/local/Cellar/maven/3.3.9 path. Then i edited my ~/.bash_profile file and put the following entries
export M2_HOME="/usr/local/Cellar/maven/3.3.9"
export PATH="$PATH:$M2_HOME/bin"
now when i try mvn -version maven throws the error that
Error: Could not find or load main class org.codehaus.plexus.classworlds.launcher.Launcher
Did i configure it wrong ?
EDIT: Maven folder
$ tree -L 2 $M2_HOME
/usr/local/Cellar/maven/3.3.9
├── INSTALL_RECEIPT.json
├── LICENSE
├── NOTICE
├── README.txt
├── bin
│ ├── mvn
│ ├── mvn.cmd
│ ├── mvnDebug
│ ├── mvnDebug.cmd
│ └── mvnyjp
└── libexec
├── bin
├── boot
├── conf
└── lib
I have also seen as an option:
Create a file ~/.MacOSX/environment.plist with:
{
"M2_HOME" = "/usr/local/Cellar/maven/3.3.9/libexec";
"M2" = "/usr/local/Cellar/maven/3.3.9/libexec/bin";
}
and restart / log back in. This would make tools like IntelliJ also pick it up.
However in my case, I found some other setup script had installed an export for M2_HOME in my .profile which broke the maven install.
I have an existing 2000 LOC perl script with a Tkx GUI that I just inherited on my first day as an intern at a place where I am the sole programmer (everyone else is an IC engineer, but they do their simulations in perl).
The goal is to produce an executable for clients to run without having to install perl nor anything else. Apparently this has been possible in the past.
I've only been able to get the Program to build by installing ActiveTcl 8.5.15, ActivePerl 5.16, installing via PPM Win32::API and Win32::Exe, tk, tkx, Carp, then installing via cpanp i PAR::Packer. This very specific mix is the only one I found that produced any results that worked.
Then it's:
pp -vvv -l C:\Perl\lib\auto\Tcl\tkkit.dll -l C:\Perl\lib\auto\Tcl\Tcl.dll -l C:\Perl\lib\auto\Win32\API\API.dll --gui -o .\<THE NAME OF THE FILE.EXE> .\<PERL SOURCE>.pl
From here I get a working executable, except it will not run on any of the other machines I've tested it on. It's not an arch issue as far as I can tell.
The documentation by the previous developer is extremely lacking on the subject (he's better on documenting the actual code). I'm told he migrated it to StrawberryPerl then back to ActivePerl when that broke, but as yet it's still pretty broken over here and the existing build environment is long gone.
Any help would be appreciated.
Action: Use PAR::Packer pp to compile Windows binary from a perl script so that clients can run it without perl
Expected Result: A tk GUI Window opens and stays open.
Actual Result: A tk GUI Window does not open, no errors are produced on console nor in any prompt.
Thanks to all who responded.
I actually found the solution myself, which was that this block
BEGIN { if (exists $ENV{PAR_PROGNAME}) { use Config (); $ENV{PERL_TCL_DL_PATH} = catfile($ENV{PAR_TEMP}, 'tkkit.' . $Config::Config{dlext}, ); } }
needs to appear before a "use Tkx;" to properly instruct PAR::Packer to grab the necessary parts of Tcl to package the program. So the necessary libraries were being left out and the executable was searching for ActiveTcl installations in %path% that did not exist. But thank you for the detail about the additional module for debugging.
This is my solution on Windows 7 with strawberry perl 5.26.1 and tkx 1.09:
pp --compile --noscan --dependent --compress 6 hello.pl
Copy generated .exe and needed dlls to a directory, and rename this directory to bin
Copy tcl and tk library to lib directory on the same hierarchy as bin
Now my generated file structure:
$ tree -L 2
.
├── bin
│ ├── hello.exe
│ ├── hello.pl
│ ├── libgcc_s_dw2-1.dll
│ ├── libstdc++-6.dll
│ ├── libwinpthread-1.dll
│ ├── perl526.dll
│ ├── tcl86.dll
│ ├── tk86.dll
│ └── zlib1.dll
└── lib
├── tcl8.6
└── tk8.6
BTW, the whole folder can be compressed to about 2.7MB by 7-zip on my machine.
I am developing a ruby gem which will have a binary.
I am trying to develop the binary but i am worried its not finding my requires because the gem isnt installed as a gem is there a way to test the binary without packaging it as a gem?
#!/usr/bin/env ruby
require "middleman_ember_scaffold/load_paths"
# Start the CLI
MiddlemanEmberScaffold::Cli::Base.start
sits in a file named mse and ive added my bin folder of gem to path
.
└── middleman_ember_scaffold
├── Gemfile
├── LICENSE.txt
├── README.md
├── Rakefile
├── bin
│ └── mes
├── lib
│ ├── middleman_ember_scaffold
│ │ ├── cli.rb
│ │ ├── load_paths.rb
│ │ └── version.rb
│ └── middleman_ember_scaffold.rb
└── middleman_ember_scaffold.gemspec
4 directories, 10 files
when i run mes i get
/Users/justin/.rvm/rubies/ruby-1.9.3-p362/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require': cannot load such file -- middleman_ember_scaffold/load_paths (LoadError)
from /Users/justin/.rvm/rubies/ruby-1.9.3-p362/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
from /Users/justin/middleman-generator/middleman_ember_scaffold/bin/mes:7:in `<main>'
i'd like to be able to run and develop mes without re-packaging everytime i make a change.
Probably a "better" way would be to do the following:
$ ruby -I./lib bin/mes
It does the same as changing your load path, but it only does it for the command you're executing.
Use RUBYLIB Environment Variable
The problem you're facing is that your source directory isn't getting some of magic applied to installed gems, and therefore doesn't have your lib directory in the $LOAD_PATH. While there are other ways to deal with this, for testing I'd recommend just adding your lib directory to the RUBYLIB environment variable. For example:
RUBYLIB="/path/to/middleman_ember_scaffold/lib:$RUBYLIB"
export RUBYLIB
bin/mes
should work for any Bourne-compatible shell. If you're running Bash, and don't have anything else stored in RUBYLIB, you might even be able to shorten the invocation to:
RUBYLIB="/path/to/middleman_ember_scaffold/lib" bin/mes
Either way, once Ruby knows what directories it should add to the $LOAD_PATH everything should work just fine.
I have a weird problem when trying to package a Firefox add-on built using version 1.9 of the SDK. The extensions directory structure is something like this:
├── data
│ ├── file1.js
│ ├── file2.js
│ ├── jquery.min.js
│ └── uri.js
├── lib
│ ├── file3.js
│ ├── main.js
│ ├── services
│ │ ├── file4.js
│ │ ├── file5.js
│ │ └── file6.js
│ └── uri.js
├── package.json
└── package.json.backup
As part of the build process, I am running the data and 'lib` directories through uglify.js. This appears to work fine. Basically I copy the codebase to a different location, run it through uglify and I get the same directory structure except the JS files are compressed.
Next, I run cfx xpi --pkgdir=path/to/ugly/codebase to package the code into an xpi.
If I then move the produced .xpi to a new directory, unzip it with unzip and inspect the contents, most of my lib directory has been deleted. Files in the data directory are fine.
tree resources/addon_name
resources/addon_name
├── data
│ ├── file1.js
│ ├── file2.js
│ ├── jquery.min.js
│ └── uri.js
└── lib
└── main.js
If I don't uglify the JS files then everything seems to work fine and when I unzip the xpi I will have a full lib directory as I would expect.
Note that this is not a problem with the uglifying process (that was the first thing I checked). When I copy the codebase and uglify it, I can stop the process at that point and list the lib directory. It will contain all the uglified JS files I would expect. It's only after packaging and subsequent unzipping that they are gone.
I have tried reproducing this issue with a brand new extension but I get a slightly different problem. Basically, files in the lib directory are deleted on packaging regardless of whether they are compressed or not. Basically my steps are:
mkdir test_extension
cd test_extension && cfx init
touch lib/uri.js // this is
cd .. && cfx xpi pkgdir=test_extension // Have to run this part twice to get ID
mkdir unpack && mv test_textension.xpi unpack
cd unpack
unzip test_extension.xpi
ls resources/test_extension/lib
=> main.js // the uri.js file is missing
If lib/uri.js is not required from any js file of your add-on, it will
be removed from the final XPI. So if you have require('./uri.js') in
your main.js, the file should be there after the packaging.
My guessing is that uglifying the libraries makes
impossible for the current cfx tool generates the proper manifest with
all dependencies. See Manifest Generation.
Note original post on mozilla-labs-jetpack mailing list, copied the answer here to be useful to someone else that doesn't know the ML.