I am currently building an autotools-based package for buildroot but I only need some parts of the actual build output (shared libraries and a handful of tools). Is there a way to install only what I need, similar to debian's *.install files when a package should be split up (like a libfoo and libfoo-dev package). If there is no other way, I will have to use the LIBFOO_POST_INSTALL_TARGET_HOOKS but I would like to know if there is a better option.
I know of the LIBFOO_CONFIG_SCRIPTS variable, but this only remove files in the /bin directory and I would like to remove them from other places too (libexec, /var, ...). This method also feels hacky for non-config scripts related to that library.
If there are no autotools configure flags to alter the installation options, one simple method is to patch the Makefile.am as required.
Here are the steps :
Alter the source Makefile.am capturing your changes in a patch(s).
Copy your patches to the global patch directory, they will be applied before building the package.
Remove the package's output/build directory and rebuild it.
At this point, the undesired files will not be installed to the target.
The more detailed method for doing this is to "make package". Go to the package's src. Run quilt to auto-generate patches for you. Alter the sources (Makefile.am), refresh the patches. Copy the patches back to buildroot's global patch directory. Once done, buildroot will patch Makefile.am then it will generate the appropriate Makefiles and will not install as required.
Here is an example :
Assume you have set BR2_GLOBAL_PATCH_DIR="$(BR2_EXTERNAL)/patches"
make package
cd output/build/package
quilt init . # output/build/package/patches now exists
quilt new 001-Makefile.am.do.not.install.patch
quilt add src/Makefile.am
# you edit src/Makefile.am here
quilt refresh # now patches/001-Makefile.am.do.not.install.patch exists
mkdir patch/to/global/patches # see BR2_GLOBAL_PATCH_DIR above
cp patches/*.patch patch/to/global/patches
cd ../../.. # got back to buildroot root to make
rm -rf output/build/package
make package
At this point, your patches should be applied to the src code and the files you removed from the make install process will not be on the target.
Make sure PACKAGE_AUTORECONF = YES in the package.mk file, it forces buildroot to autoreconf.
Related
I'm new to stackoverflow so correct me if I made any mistake in providing the details.
So I'm trying to make a deb file for Apache-Age, and going by the documentation, if we try to install AGE from source then we can simply do it by :
make install
I have setup the basic directory structure by dh_make and have made the control file with proper dependencies, then comes the rule file.
So I went through 2 different extensions of postgreSQL :
postgresql-q3c
Postgis
And tried to replicate the same for apache-age, and tried to build by following commands
dpkg-buildpackage -rfakeroot -b
dpkg-buildpackage -nc -i
the build was giving some errors and warning but a deb file was generated.
The deb file installed properly but age-extension was not installed in PostgreSQL.
It's probably because the age was not building properly from source using make command as specified in the rule file.
Is there any good resource or how to make rule file ?
I tried following this answer, but got stuck here.
I found a PDF but didn't understand the build process.
This might be a naive way but it works for me:
Clone the repo and cd to it
Run the dh_make_pgxs command to make the debian build directory structure.
The you need to make changes to pgversion, control/control.in, changelog, copyright and rule files.
If you are just trying to use the make file to build the package then the rule file can be as simple as:
#!/usr/bin/make -f
%:
dh $#
Then simply run the build command as before.
I created a Bitbake recipe that does two things: 1) build an out-of-tree kernel module, and 2) copy files into the target root filesystem.
Part 2) uses the update-alternatives class to choose which files to copy based on the package that's being installed, ie, ${PN}-package, similar to the way the "linux-firmware" recipe works.
I also use EXTRA_OEMAKE (as part of the modules class) to pass variables down to the Makefile for the module I'm building. What I would like to do is to select different variables in EXTRA_OEMAKE based on which package is specified, ie, package1, package2, etc.
Is there a way to do this, or can anyone suggest any alternatives?
How do I import an external package from scratch?
I've written a library package in Go and testing to distribute through github. I am following http://golang.org/doc/code.html and using mac but getting error message
cmd I put is following.
$ mkdir $HOME/go
$ export GOPATH=$HOME/go
$ export PATH=$PATH:$GOPATH/bin
$ mkdir -p $GOPATH/src/github.com/user
$ mkdir $GOPATH/src/github.com/user/project
Then I put
$ go get github.com/user/project
Still errors with go install
can't load package: package github.com/golingorg/goling: no Go source files in /Users/user_name/go/src/github.com/user/project
I do not understand why we need files to import an external package in Go. External package means that I get something and create files from the external package.
My question is how I import an external package from scratch. Most of documents just say something like
go get github.com/yasushi-saito/fifo_queue
this gives me "$GOPATH not set."
I am getting frustrated setting up the environment for "go get" to work, as a beginner. Thanks a lot in advance.
Summary
How do I import an external package from scratch?
Go is a static type language thus it needs to resolve any reference to external package at compile time. The "go" tool expects the source of external packages in locally accessible path thus you need to use "go get" to download them.
From what you described, you probably did not set the GOPATH. Use ECHO $GOPATH to check if it is set correctly.
For my GO project, I normally use GOPATH as workspace, similar to virtualenv in Python or rbenv/rvm in Ruby. Let say my project "myproject" has root at /projects/myproject, my source file will be located at /projects/myproject/src/myproject and there is an import of "github.com/user/project", then
> cd /projects/myproject
> export GOPATH=`pwd` # or export GOPATH=/projects/myproject
> go get github.com/user/project
After "go get" command, the source of "github.com/user/project" will be downloaded to /projects/myproject/src/github.com/user/project.
When you use "go build" or "go install" then, it will compile as the external packages is in the $GOPATH/src folder.
If you install Go in the default folder, you need to include Go installed bin folder in the PATH environment variable. After that GOPATH is the other environment variable you need for "go" tool to work.
That's how I done it:
1. Setup your workspace first
mkdir $HOME/go
export GOPATH=$HOME/go
export PATH=$PATH:$GOPATH/bin
2. Create the project
mkdir -p $GOPATH/src/github.com/user
mkdir $GOPATH/src/github.com/user/hello
touch $GOPATH/src/github.com/user/hello/hello.go
3. Install it
go install github.com/user/hello
4. Run it
cd $GOPATH/bin
./hello
I used the following vagrant image: https://github.com/dcoxall/vagrant-golang
From the help output for go get, it says:
By default, get uses the network to check out missing packages but does not use it to look for updates to existing packages.
When you created the $GOPATH/src/github.com/user/project directory prior to running go get, it assumed that the package had already been downloaded so skipped to the step of trying to build and install the package. That failed because the directory contained no Go source files.
So the simple fix is to not create the folder associated with the package you are trying to download: go get will do that for you.
I am creating rpm for apc. While writing spec file, I realized that some commands may have path which can keep on changing which are required during the compilation time. For eg. these commands are required to be executed during the building time.
$ /usr/local/php/bin/phpize
$ ./configure --with-php-config=/usr/local/php/bin/php-config
But the complete path of phpize and php-config file may change. So how can i prevent this dependencies so that i should not hard-code these path in my spec file.
Because these commands are used at building time, the ideal solution to this problem is here:
Find packages on distribution which provide these commands or paths e.g php-config is provided by php-devel package on Fedora operating system. In fedora you can find it using yum whatprovides "*/php-config" or if they are already installed on system then using rpm -qf /path/to/command.
Once you know the packages add them as BuildRequire tag in spec file. Step 2 will make sure that paths are always present whenever you build the package from spec file even if you use hard coded paths (which isn't ofcourse best way to do it).
In place of /usr/ you can use %{_prefix}, it depends entirely on macros available on distribution you are building this rpm on. Check macro files for path macros. One link which has common macro definitions is here.
I just want to develop a C app in linux with the auto(make/conf/...) stuff automatically generated. I tried generating it with ede and anjuta, but it doesn't seem to generate Makefile.am. So, I tried running automake, and it says "ltmain.sh" isn't found. Is there some easy to generate the basic build files for linux C/C++ apps. What is the standard practice? Do most people write these files themselves?
Generating a really trivial set of autotool files is pretty easy. Here's a (really basic) example. After you run these, you should get a copy of ltmain.sh in the directory, and you'll be all set to run the configure script:
$ mkdir sample
$ cd sample
$ echo 'int main( void ) { return 0; }' > foo.c
$ echo 'bin_PROGRAMS = foo' > Makefile.am
$ autoscan
$ mv configure.scan configure.ac
$ # edit configure.ac, add AM_INIT_AUTOMAKE([foreign])
$ # and LT_INIT, set project name and bug-report-address
$ autoreconf -ivf
Note that in this example, libtool really isn't necessary since
the example is just building a simple app. But you asked about
ltmain.sh, and that's a libtool thing so LT_INIT is needed to
address that portion of the question. If you want to build
a library, change bin_PROGRAMS to lib_LTLIBRARIES.
EDE can work with your Automake files in two different ways. If you write your own automake files, it will read them, and tweak them via the UI.
If you prefer, you can have EDE do the whole thing for you. First, create your first C file, then when it is on disk, do:
M-x ede-new RET Automake RET
then from the project/project options menu, add a target, like "program".
If you fill in your C file, you can then choose Project->Build->build currentproject from the menu, and it will create and setup everything needed for Automake to do it's thing, in addition to running all the misc automake commands needed.
Lastly, there is a 'run' option somewhere to run your program.
I'd consider not using autoconf and automake at all -- their complexity outweighs their benefit, particularly if you're targeting only Linux.
Note that "git", for example, doesn't use them at all; instead it simply has a moderately-complex (but comprehensible) Makefile.