I have downloaded an open source project from GitHub, I want to use Xcode open it can make changes.
but when I open it I get error, can not open file:
how to solve this issue?
You need to follow the instruction in the INSTAll file
Varnish uses the GNU autotools. To build and install Varnish, simply
run the 'configure' script in the top-level directory, then run 'make'
and 'make install'. On Linux, you need to run 'ldconfig' as root
afterwards in order to update the shared library cache.
If you obtained the sources directly from the Git repository, you will
need to run autogen.sh first to create the configure script.
Varnish will store run-time state in $localstatedir/varnish; you may
want to tune this using configure's --localstatedir parameter.
Additional configure options of interest:
--enable-developer-warnings
enable strict warnings (default is NO)
--enable-debugging-symbols
enable debugging symbols (default is NO)
Related
I am getting a stuck while trying to create a Terraform provider. I have been following the advice given on https://www.terraform.io/docs/extend/writing-custom-providers.html but when I go to build my binaries via Go go build -o terraform-provider-example I get several missing packages errors.
So I then work my way down the list of missing packages and use go get ... to get those packages installed in my Go libraries.
I get an error indicating that github.com/hashicorp/hcl/v2 cannot be found. I navigate to the location and sure enough it doesn't exist.
Package not available at install time screen shot
Package not available with go get
So I am getting stuck and unable to build these providers. I have looked for a while now trying to find something which describes how to setup the environment for creating providers but have been unsuccessful so far. Can anyone help get me going?
Terraform Core and Terraform provider development requires using the Go toolchain in the new "modules mode", which in current versions of Go is not the default.
The easiest way to ensure you're working in modules mode is to clone the repository you want to work on outside the $GOPATH/src directory. Development outside of GOPATH is only supported in Modules mode, and so the Go toolchain assumes that you intend to use modules mode if you are working in that way.
One reason why Terraform development requires modules mode (though not the only one) is that it has a dependency on github.com/hashicorp/hcl/v2, which is a module path type that is not supported in the old GOPATH mode because previously the Go toolchain was only able to install from the master branch of a particular remote dependency in a Git repository. The module path github.com/hashicorp/hcl/v2 is the Go Modules way to specify using the second major version of HCL, whereas github.com/hashicorp/hcl is the first major version.
In modules mode, it should be sufficient to just run go build -o terraform-provider-example (or, if you prefer, go install) and it will automatically fetch the dependencies to the local modules cache and use them from there. In modules mode, go get is for changing the dependencies recorded in go.mod rather than for installing existing dependencies.
I am trying to install chromaticity on my own machine for testing, and no matter what i do i will always hit the error seen in this picture installation error
I dont know why it happened i tried searching but i found nothing online. my question is does anyone know why it happens? or can point me to the right direction? i have checked the folders and yes there are no GO files in there but i dont see why that is a problem
The api could be found here: https://github.com/evq/chromaticity
This is not an issue (as in bug) on the project, rather an issue due to lack of documentation on how to build the project itself.
If you look at the Makefile file on the root directory, you'll notice that static/static.go is a generated file as part of the build process. Such file is usually not committed to the repo so you'll need to build it yourself. To do so, you'll need to have go-bindata installed.
Here's what you need to do in order to build the project successfully:
Get the go-bindata package
go get -u github.com/jteeuwen/go-bindata/...
Get the project
go get github.com/evq/chromaticity
Go the project root directory
cd [...the chromaticity project root..]
Run make to generate the static/static.go file
make
Build/ install the project
go install
Update:
Noticed from your screenshot that you're using Windows, in that case you may need to workaround the issue of running Makefile in Windows. See here for possible solution: How to run a makefile in Windows?
I've run into the same issue when trying to "get" and then install this project. I looked into the code and there is no trace of Asset() function in github.com/evq/chromaticity/static. Moreover git history does not show any .go files in static/ directory. Personally, I would create issue in the project and/or look for different repo containing desired functionality.
I'm editing and testing a package that I'd like to build via macports. Is there a way that I can force macports to fetch and build the package from my repository? I've edited my Portfile to point to a single repository but it seems to be ignoring it.
MacPorts uses curl internally to download files, which gives you a couple of options to switch where stuff is downloaded from:
You can use file:// URLs in the master_sites property of the Portfile to point to a local directory. Note that the fetch runs as the macports user, so make sure that user is allowed to read files from that directory.
For file downloads, you can replace the cached file. MacPorts will use your replacement the next time it extracts the source code of a port. Run port distfiles $portname to find the local path where a file may be cached.
You can switch to git for fetching by setting fetch.type git, git.url to whatever git clone will accept to clone your repository (which can be local) and optionally git.branch to a commitish you want to check out. See https://guide.macports.org/#reference.phases.fetch.git for details. Again, make sure that the macports user can read the local files if you use a local git repository.
Any other version control system supported by MacPorts; see the guide for details.
Note that MacPorts caches file downloads by default (no caching is applied for version control systems at the moment), so if you did not modify the filename, you will have to run sudo port clean --dist $portname to delete the cache.
When building modified versions of ports, you'll also have to look out for a number of other points:
MacPorts will download a precompiled binary if one is available. Since that precompiled binary will not match your modified Portfile or source code, pass the -s flag to port to force building from source.
MacPorts will not compile a port if you run 'port install' and it is already installed (either activated or deactivated).
Probably the easiest solution to work around these two potential pitfalls is running sudo port destroot $portname instead of sudo port install. This will run all steps up to (and including) make install, but will not actually put the files into /opt/local. If you can debug what you need to debug from the build directory at port work $portname, this will simplify things.
I know that this should probably be very easy, and I have looked into the read me files and other files in cgdb like INSTALL that talk about isntalling cgdb. I was trying to install cgdb and the instructions said:
$ ./configure --prefix=/usr/local
$ make
$ sudo make install
However, there is no such file inside of the file I got from running the git clone command. i.e. from running:
$ git clone git://github.com/cgdb/cgdb.git
I went inside that file to see the installation instructions and it says the following:
Basic Installation
==================
These are generic installation instructions.
The `configure' shell script attempts to guess correct values for
various system-dependent variables used during compilation. It uses
those values to create a `Makefile' in each directory of the package.
It may also create one or more `.h' files containing system-dependent
definitions. Finally, it creates a shell script `config.status' that
you can run in the future to recreate the current configuration, a file
`config.cache' that saves the results of its tests to speed up
reconfiguring, and a file `config.log' containing compiler output
(useful mainly for debugging `configure').
If you need to do unusual things to compile the package, please try
to figure out how `configure' could check whether to do them, and mail
diffs or instructions to the address given in the `README' so they can
be considered for the next release. If at some point `config.cache'
contains results you don't want to keep, you may remove or edit it.
The file `configure.in' is used to create `configure' by a program
called `autoconf'. You only need `configure.in' if you want to change
it or regenerate `configure' using a newer version of `autoconf'.
The simplest way to compile this package is:
1. `cd' to the directory containing the package's source code and type
`./configure' to configure the package for your system. If you're
using `csh' on an old version of System V, you might need to type
`sh ./configure' instead to prevent `csh' from trying to execute
`configure' itself.
Running `configure' takes awhile. While running, it prints some
messages telling which features it is checking for.
2. Type `make' to compile the package.
3. Optionally, type `make check' to run any self-tests that come with
the package.
4. Type `make install' to install the programs and any data files and
documentation.
5. You can remove the program binaries and object files from the
source code directory by typing `make clean'. To also remove the
files that `configure' created (so you can compile the package for
a different kind of computer), type `make distclean'. There is
also a `make maintainer-clean' target, but that is intended mainly
for the package's developers. If you use it, you may have to get
all sorts of other programs in order to regenerate files that came
with the distribution.
and there is more I didn't paste.
The part that confuses me is the following paragraph:
The file `configure.in' is used to create `configure' by a program
called `autoconf'. You only need `configure.in' if you want to change
it or regenerate `configure' using a newer version of `autoconf'.
does it mean I should run ./configure.in? I am honeslty a little scared of running it because I need to run it in as sudo plus, that file doesn't even exit in the code I got from git clone. This is what I do have in that directory:
➜ cgdb git:(master) ls
AUTHORS Makefile.am autogen.sh doc roadmap.txt
COPYING NEWS autorelease.sh indent.sh test
ChangeLog README cgdb lib
FAQ README.md config packages
INSTALL TODO configure.init release-todo.txt
➜ cgdb git:(master)
I did grep for config or config.in in that directory and it didn't yield anything useful.
I have also tried brew installing it but I ran into problems. When I cgdb the file and hit run it frozen at a print statment instead of moving on to the next command prompt for gdb as in (gdb). Anyone knows whats up? Is it because I am using go source file?
What have people done to have cgdb working on a mac?
Неу, yeah, the git source for cgdb doesn't come with the configure script pre-built. (The official release distributions do, however.)
If you have the right tools installed, you can fix this by running:
./autogen.sh
This will generate the configure script, and then you can install it as you would any other autoconf-based source package.
Forget about all that aggro with configuration and dependency libraries; install MacPorts and do:
$ sudo port install cgdb
They have 0.6.7 at the time of writing.
What worked for me was doing:
brew install cgdb
However, for me that was not enough to get it going. I needed to sudo it for it to run:
sudo cgdb
I would have never guessed I needed to sudo it...I figured it out because it was throwing me the error talked about in the following question:
gdb fails with "Unable to find Mach task port for process-id" error
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