I need to use "configure --prefix" in order to "make install" in a particular location. Only a makefile is provided, not a configure file. I have never used autoconf or created a configure script myself. I found a guide here, but got lost at the 5th step involving target binaries etc. Is there any way to make install in the location I need it to be in without creating a configure file. If not, is there any easy way (or a simple guide/tutorial) to make a configure file?
Your question is not very clear to me. Are you trying to create a configure for a package you authored, or are you trying to install some (unnamed) package that does not follow the GNU Build System conventions? I'm assuming the latter.
If the package you are trying to install does not come with a configure file, there is no point in trying to run ./configure, and I would advice against building one unless you are very familiar with that package (and in that case you would know how to install it).
Without knowing what package it is, I would suggest the following course of actions:
Search this package's README files or web pages for instructions about installation.
Look into the Makefile. Maybe you will find a simple install rule and all you have to do is edit that rule or some variable to point to the desired location. Some package are so simple they don't even come with an installation rule: for instance they maybe build a binary, and you are expected to copy that binary wherever you want by your self.
Contact the author(s) of that package.
Related
I can specify dependencies to be downloaded by go get after checking out my project by importing them. I can even force the download of packages that are not used in the code by importing them for side effects:
import _ "github.com/jteeuwen/go-bindata"
Furthermore, on the shell I can apparently install a program with go get by using an ellipsis after the path:
$ go get github.com/jteeuwen/go-bindata/...
However, it seems I cannot combine both techniques:
import _ "github.com/jteeuwen/go-bindata/..."
$ go get
main.go:9:8: open c:\gopath\src\github.com\jteeuwen\go-bindata\...: Access denied
I would like to tell go get that for building (actually go generateing) this project, go-bindata has to be installed. Is it possible to specify install-dependencies?
To answer your question: No.
But you could vendor go-bindata into your project which would make it available after after go geting your project.
But maybe there is a slight confusion about when and why to run go generate: The intended use for go generate (as I understand it) is for package or command authors to generate code during the development phase. Code which is checked in and processed "normally" by go {build,install,get}. So you run go generate, check in the generated stuff and users of your package go get it and do not run go generate. They don't need to, the code comes in the proper checked in version during geting.
For more complicated builds which a end-user has to perform: Use Makefiles or similar tools as such stuff is out of the scope of go get.
In one of my projects I use Godep. According to its page:
This tool assumes you are working in a standard Go workspace, as
described in http://golang.org/doc/code.html. We expect godep to build
on Go 1.4* or newer, but you can use it on any project that works with
Go 1 or newer.
You'll have your dependencies in a JSON file, just like Node, Bower, etc... It's vert simple to use.
In your case, assuming you already have go geted the package, run:
godep save
This will generate the JSON file with all your other dependencies and save to a folder in your project. Thanks to it I was capable of cross compiling my project.
I have a source tree that can build two different projects from the same source. You call make A or make B, and the code is affected by ifdefs and similar using preprocessor variables to make two versions of the output. I'm looking to make dpkgs for these, and can make one fine, but am unsure of a good way to do this.
Currently I run dpkg-buildpackage, and I get A.deb or similar. Is there a way to do dpkg-buildpackage -target B so that it would then build a debian package for that project?
Things such as Creating multiple packages with dpkg-buildpackage seem to refer to having separate source code for the separate projects, which is not the case here.
I am in control of the source code so can make changes there.
Thanks.
You can set up one rules file to build two separate Debian packages at the same time. But if they are unrelated, this is an abuse of the Debian packaging procedure. It's designed for building multiple related Debian binary packages from a single source.
I am trying to compile the following software so that I can step through and debug it. I am only a novice programmer and I am trying to understand how this whole makefile business works with Fortran. I know that there is a ton of literature on makefiles but I just need to insert a simple debug flag and I think if someone provided me with the answer to this question that would be the best way for me to learn.
So the program I am trying to compile, TINKER, is actually made up of several packages, located at http://dasher.wustl.edu/tinkerwiki/index.php/Main_Page. I would like to compile and debug JUST ONE specific executable, "analyze". I contacted the developer and received the following reply but I am still stuck...
Since TINKER has lots of small source code files, what we do is
compile each of the small files to an object file using the "-c" flag.
Then we put all of these object code files (ie, the ".o" files) into
an object library. Finally, we link each of the TINKER top level
programs, such as "analyze", against the object library. There is a
Makefile supplied with TINKER that does this. We also supply
individual scripts called "compile.make", "library.make" and
"link.make" for various CPU/compiler combinations that can be run in
order to perform the steps I describe above. To build a "debuggable"
executable, you just need to include the appropriate debug flags
(usually "-g") as part of the compile and link stages.
I am currently running OSX 10.6.8. If someone could show me which folders I cd into, what commands I enter that would be so great!
Thanks!
My follow up question (once I can figure out how to answer the above via command line will concern how to import the same procedure but using the Photran IDE - http://wiki.eclipse.org/PTP/photran/documentation/photran5#Starting_a_Project_with_a_Hand-Written_Makefile)
The directions are at http://dasher.wustl.edu/tinkerwiki/index.php/Main_Page#Installing_TINKER_on_your_Computer
Maybe out of date? g77 is obsolete -- it would be better to use gfortran.
The key steps: "The first step in building TINKER using the script files is to run the appropriate compile.make script for your operating system and compiler version. Next you must use a library.make script to create an archive of object code modules. Finally, run a link.make script to produce the complete set of TINKER executables. The executables can be renamed and moved to wherever you like by editing and running the ‘‘rename’’ script."
So cd to the directory for the Mac -- based on "we also provide machine-specific directories with three separate shell scripts to compile the source, build an object library, and link binary executables." Then run the command scripts. Probably ./compile.make. Look around for the directories ... you can probably figure it out from the names. Or search for the file "compile.make".
Or find someone local to you who knows more about programming.
I am trying to make a live CD for simplifying chrooting into unbootable Linux systems for users, as many unbootable Linux issues could be fixed with chroot, but many users probably don't understand the concept of chroot.
One of the abilities I want to add is the ability to temporarily import some utilities from the Live CD into the target system, so that they can be used as if they where installed, to do configuration tasks.
The problem is is that I can't seem to work around the apps trying to search for stuff in /usr/share when they are imported. (I already have a hacky workaround for /usr/lib using patchelf...) I would do a union mount on the /usr/share's, but that could confuse some package managers when they see files that should not be there, as the user might need to run a package manager to fix the broken system. (or at least I think it could confuse package managers).
I'm trying to see if I can create a script that will rebuild all packages to use a different build prefix instead of /usr. The script can rebuild packages with apt-get build-dep/apt-get source/debbuild, but it can't change the prefix.
Question: Is there a way to pass an argument to debuild or dpkg-buildpackage to change the build prefix?
Right now it seems I have to take a look at the contents of the source (from apt-get source) for every package and see what files are specifying /usr and figure out a way to change it for every one, but I have a feeling I'm missing something obvious...
Is this possible?
I don't think this is feasible. Why don't you mount in a different location, for example /usr/local? That way, you also eliminate a source for possible conflicts.
Still, some packages are full of hardcoded references to the location for their data files, for example.
I'll throw in a pointer to stow as well, although I imagine it's not really helpful for your scenario.
we call Mac PackageMaker from an Ant script, to build our product installation package.
I would like to pass a parameter 'productConfiguration', that will direct the package to include or exclude certain components, e.g. in order to create a smaller Trial version package.
What is the correct way to achieve that?
Notes:
In Windows we use InstallShield's Features, Conditions, Release Flags, Configuration Flags.
Are there similar concepts in PackageMaker?)
Where is the documentation of pkmkdoc spec 1.12?
The only way I can think of, is to generate [some of] the xml files inside the install.pmdoc smart folder, using templates. But it looks very inelegant to me.
Packagemaker doesn't contain a lot of sophisticated features for things like this. I would suggest tweaking the ant script by creating a separate build target that builds the trial installer. This target can customize both the files included and the PackageMaker parameters.