src2pkg-2.9 - build .pets from source code!

[amigo]

OPTIM_FLAGS is what contains the optimization flags. There is a shortcut for either of the settings you mention:
OPTIMIZE_4_SIZE=YES
gives you -Os
OPTIMIZE_4_SPEED=YES
gives you -03
(the default gives you -O2)

I know it a little confusing, but the final options are composed from several elements, each of which can be set individually.
STD_FLAGS="$(echo $OPTIM_FLAGS $MACHINE $EXTRA_FLAGS $TUNE_FLAGS )"
MACHINE is normally '-m32' unless the system is 64-bit.
TUNE_FLAGS is composed from MARCH_FLAGS and ARCH_FLAGS
You can see the code where this is happening in /usr/libexec/src2pkg/01-pre_process. The settings then get used in /usr/libexec/src2pkg/06-configure_source. (Search for STD_FLAGS)

You might want to set the follwoing values in src2pkg.conf file:

Code: Select all

[[ $EXTRA_FLAGS ]] || EXTRA_FLAGS="-pipe -fomit-frame-pointer -fno-strict-aliasing -Wno-shadow -Wno-unused"
[[ $EXTRA_LDFLAGS ]] || EXTRA_LDFLAGS="--relax,--sort-common,--no-keep-memory"

It's important to note that using this sort of syntax:
[[ $EXTRA_FLAGS ]] || EXTRA_FLAGS=
instead of simply:
EXTRA_FLAGS=
allows you to override these settings on a per-package basis, so I recommend always using such syntax in the conf file.

[anikin]

amigo,
I have one more question, not directly related to src2pkg - LDFLAGS.
At what point/stage do they come into play? They are not needed for ./configure, they are not needed during make, I guess. They can be exported, but when? How would a normal sequence of commands look like, if I performed a manual compiling?
1) ./configure
2) make
3) export LDFLAGS ?
4) make install

Thank you in advance.

[amigo]

No, CFLAGS and LDFLAGS are used during configuration:
export CFLAGS
export CPPFLAGS (if using g++)
export LDFLAGS
configure
make
make install

However, the procedure varies a great deal, depending on the sources and configuration method. Not one of the above commands is universal and always used. This is where src2pkg really helps because it understands dozens of variations and detects when to use the right method.

[anikin]

Thanks, amigo.

I have some basic understanding of CFLAGS and need to read more about LDFLAGS. No doubt, src2pkg is a powerful and sophisticated tool and I will be using it. It's well crafted and documented, and I want you to know, that your work is greatly appreciated. The only beef I have with it is its input part. I'd like it to be a little bit simpler, more intuitive. Something like that of buildpets', where I can have all the options at a glance. I just instinctively expect them to be seen in one place. Please, consider this a feature request.

Thank you.

[amigo]

Well, having every option in just one place is problematic -wherever that one place is.

If everything must be explicitly given in a build script, like buildpet, then changing common configuration options would require you to edit every build script -after first requiring that there *be* a build script for the source. If every common option was held in a single configuration file then you wouldn't be able to adjust, for instance, CFLAGS for just one package -this is what gentoo's 'emerge' limits you to.

I've tried to make it possible to build some things without any package-specific build recipe and also without any general config file at all -this means that some sane defaults will always be set no matter what. If you want to adjust the default value for all builds, for CFLAGS, for instance, then that should go in the main config file at /etc/src2pkg/src2pkg.conf. If you use the conditional syntax suggested earlier, then you can still override the setting from the command-line or from within a build script.

Many options are best seen as being transitional -like cleanup functions, etc., which can be turned on and off from the command line. Build scripts should only contain stuff which is critical and/or indispensable to that specific build. The whole system is designed to encourage the use of build scripts -unless the absence of one means that everything is done automatically without any special non-transitional options. Any software build is only as good as its repeatability factor.

Feel free to ask me about any options you are interested in or looking for -because they are probably already in there -like package splitting or size reduction options.

[01micko]

I have a bug to report.

I know you don't like the .pet package format and have talked about dropping it. If you don't then there is a bug with the package naming in the pet.specs file.

sdl-1.2.14|sdl|1.2.14|1|BuildingBlock|596K|pet_packages-14.0|sdl-1.2.14-1.pet|unknown|No summary text for sdl|slackware|14.0||

The bold part misses the arch which does exist in the package name. I used splitting;

Code: Select all

src2pkg --splitpkg=devel,doc,nls --jobs=6 -PET2 -CWD SDL-1.2.14.tar.xz --arch=i486 -A

Also, all 3 packages contain a populated usr/doc directory.

Other than that it seems all patches were applied fine and the package works fine.

BTW, SFR found the fullscreen patch see here

Here is the generated build script:

Code: Select all

#!/bin/bash
## src2pkg script for: 	sdl
## Auto-generated by src2pkg-2.91
## src2pkg - Copyright 2005-2013 Gilbert Ashley <amigo@ibilio.org>

SOURCE_NAME='SDL-1.2.14.tar.xz'
ALT_NAME='sdl'
VERSION='1.2.14'   # Use ALT_VERSION to override guessed value
# ARCH=''
# BUILD='1'
# PRE_FIX='usr'
# Any extra options go here:
# EXTRA_CONFIGS=""
PATCHLIST='fullscreen-sdl-1.2.14.patch.gz
sdl-1.2.14-fix-mouse-clicking.patch.gz
sdl.linux-2.6.31.input_absinfo.diff.gz'
MAKE_COMMAND='make -j6'

# Optional function replaces configure_source, compile_source, fake_install
# To use, uncomment and write/paste CODE between the {} brackets.
# build() { CODE }

# Get the functions and configs
. /usr/libexec/src2pkg/FUNCTIONS ;

# Execute the named packaging steps:
pre_process
find_source
make_dirs
unpack_source
fix_source_perms
configure_source #
compile_source   # If used, the 'build' function replaces these 3
fake_install     #
fix_pkg_perms
strip_bins
create_docs
compress_man_pages
make_description
make_doinst
make_package
post_process

## See the documentation for more help and examples. Below are some of
# the most common Extras and Options for easy cut-and-paste use.
# DOCLIST='' PATCHLIST='' INSTALL_TYPE=''
# CONFIG_COMMAND='' MAKE_COMMAND='' INSTALL_LINE='' 
# When editing src2pkg scripts to add custom code, use these variables
# to refer to the current directory, the sources or the package tree:
# $CWD (current directory), $SRC_DIR (sources), $PKG_DIR (package tree)
# Other commonly-used directories include: $DOC_DIR (document directory)
# $MAN_DIR (man-page directory) $DATA_DIR (shared-data directory)

[amigo]

Thanks for reporting, micko. I don't recall seeing any pets which have the arch in them. Is this something new?

As for the docs, the content in split packages is usually not the same. Any redundant items will simply overwrite existing items. The fact that docs are not completely separated is owing to a principle: when distributing packages built from open source sources, the license should always be in there.

NLS packages may, or may not, contain binary content, depending on how you define 'binary'. To be on the safe side I have src2pkg include docs with nls packages.

devel packages contain the license and other general docs, plus any *.info and *.man pages which relate to the development parts of the package (man2 and man3).

Sometimes the content of usr/doc will be the same across all split packages -when there is only a README and LICENSE, for instance.

Docs are particularly hard to split in an intelligent way. If you try to always spit the docs you wind up with lots of tiny docs packages which only contain a couple of files. Because of this I created the DOC_SPLIT_SIZE setting, which sets a low-side size limit. The default is 100K, which means that if the doc dir contains less than 100K of docs the routine will not create a docs package even though you have asked for it.

A very long time ago, I built in the option to minimize the size of the docs, by setting DOCLIST=MINIMAL. You may wish to try that and skip splitting the docs.

I try to be helpful about creating or modifying options to fit real-life needs, but I have always refused to have src2pkg simply delete all docs from packages. I simply don't believe it is the right thing to do. I really am worse than debian on this. For debian packages, they don't ship them with a copy of the license for each package. Instead, all packages rely on a common-licenses package which contains a copy of all the common open-sources licenses. Documentation in the package (copyright and control files) refer to the relevant license. But, this means that a (sometimes) binary package has been distributed without including that license. I designed a routine which does it this way:
Each package contains a copy of its correct license -which is located in a common location(not in the package-specific doc dir)- so that each package will overwrite any existing copy of that license. The doc directory for the package then contains a symlink to that license. This means each package still contains a copy of the license, but since it is a copy which overwrites the common location, on an installed system you only have one copy of each license instead of a identical copy in hundreds of dirs under /usr/doc.

Comments or questions are welcome.

[01micko]

Thanks for reporting, micko. I don't recall seeing any pets which have the arch in them. Is this something new?

.. no not new just not widely used. In woof-CE the 'new2dir' script now gets arch from uname -m (as std in most package build scripts). Of course the disadvantage of new2dir is that it uses installwatch. I much prefer not to install when packaging. Unfortunately, not all sources support destdir so I take the lazy way out and use new2dir. Anyway, the packages of course all get correct naming, just the pet.specs may cause an issue with package management.

As for the docs, the content in split packages is usually not the same. Any redundant items will simply overwrite existing items. The fact that docs are not completely separated is owing to a principle: when distributing packages built from open source sources, the license should always be in there.

NLS packages may, or may not, contain binary content, depending on how you define 'binary'. To be on the safe side I have src2pkg include docs with nls packages.

devel packages contain the license and other general docs, plus any *.info and *.man pages which relate to the development parts of the package (man2 and man3).

Sometimes the content of usr/doc will be the same across all split packages -when there is only a README and LICENSE, for instance.

Docs are particularly hard to split in an intelligent way. If you try to always spit the docs you wind up with lots of tiny docs packages which only contain a couple of files. Because of this I created the DOC_SPLIT_SIZE setting, which sets a low-side size limit. The default is 100K, which means that if the doc dir contains less than 100K of docs the routine will not create a docs package even though you have asked for it.

A very long time ago, I built in the option to minimize the size of the docs, by setting DOCLIST=MINIMAL. You may wish to try that and skip splitting the docs.

I try to be helpful about creating or modifying options to fit real-life needs, but I have always refused to have src2pkg simply delete all docs from packages. I simply don't believe it is the right thing to do. I really am worse than debian on this. For debian packages, they don't ship them with a copy of the license for each package. Instead, all packages rely on a common-licenses package which contains a copy of all the common open-sources licenses. Documentation in the package (copyright and control files) refer to the relevant license. But, this means that a (sometimes) binary package has been distributed without including that license. I designed a routine which does it this way:
Each package contains a copy of its correct license -which is located in a common location(not in the package-specific doc dir)- so that each package will overwrite any existing copy of that license. The doc directory for the package then contains a symlink to that license. This means each package still contains a copy of the license, but since it is a copy which overwrites the common location, on an installed system you only have one copy of each license instead of a identical copy in hundreds of dirs under /usr/doc.

Comments or questions are welcome.

Thanks for your detailed explanation and after absorbing it makes sense to not split off the docs. I will try soon DOCLIST=MINIMAL.

BTW, is there any way to combine sources into one package? SDL is a classic example where the SlackBuild bundles into the base sdl package sdl-mixer, sdl-image, sdl-net, sdl-ttf,

Thanks.

[amigo]

"pet.specs may cause an issue with package management" Can you confirm whether that is the case with pets which include the 'arch'?

It is possible to build multiple sources into a single package, but src2pkg doesn't make this any easier than regular slackbuilds -at least not now. I have done some work on making this easeir, but requires major re-writing of parts of src2pkg. The idea is certainly relevant and I'm thinking lots about it as I consider re-writing much of src2pkg from scratch. I'll probably end up breaking backwards-compatibility -the 'API' for the build scripts would need to change bigtime.

Here's an example script which combines multiple sources:
http://distro.ibiblio.org/amigolinux/di ... ng.src2pkg

For stuff which is easily built and has a well-defined relationship with 'main' sources, I prefer to have separate packages. If one supposes that dependency resolution works correctly, this poses no problem. Combining packages sounds like a good idea, but isn't one. Again, if dep-resolution works, a 'meta' package could be used -that is a package which doesn't include any real content, it simply depends on the various individual packages meant to be grouped. This allows for more flexible usage.

I do find it odd that the users of a decidedly-small-size distro are the first to want to bundle lots of stuff together which other users may not need or want. for instance, someone here was working on a super-SFS which would contain all script interpretors like lua, python, perl -and while we're at it throw in QT4 & CO.? As if those things were related at all. Say I want lua which needs a few MB itself -but perl needs 25MB and python even more -all of a sudden we have a 100MB package. It is annoying to have a long list of installed packages when each are properly separate, but it gets even worse when you start splitting packages -suddenly for each unit of functionality we have 4 packages. The last time I rebuilt my local system I split all packages, but I think I will only split devel content next time.