rpm-build/tools/Makefile.am

66 lines
1.3 KiB
Makefile
Raw Normal View History

2002-03-25 23:16:26 +03:00
# Makefile for rpm tools.
AUTOMAKE_OPTIONS = 1.4 foreign
INCLUDES = -I. \
2002-03-25 23:16:26 +03:00
-I$(top_srcdir)/build \
-I$(top_srcdir)/lib \
-I$(top_srcdir)/rpmdb \
-I$(top_srcdir)/rpmio \
@INCPATH@ \
-I$(top_srcdir)/misc
EXTRA_DIST = rpmchecksig.c
depends.c: disabled tsort presentation order This should facilitate library upgrades, e.g. glibc-prthread. Consider that we upgrade gcc-* and glibc-* packages; and glibc has new subpackage glibc-pthread (with libpthread and librt shared libraries). Old order was: D: ========== tsorting packages (order, #predecessors, #succesors, tree, depth) D: 0 0 14 0 0 glibc-preinstall-2.8.90-alt3 D: 1 1 21 0 1 glibc-core-2.8.90-alt3 D: 2 1 9 0 2 cpp4.3-4.3.2-alt5 D: 3 1 5 0 2 libgcc4.3-4.3.2-alt5 D: 4 2 13 0 3 glibc-pthread-2.8.90-alt3 D: 5 2 20 0 4 glibc-core-debug-2.8.90-alt3 D: 6 2 17 0 4 glibc-gconv-modules-2.8.90-alt3 D: 7 2 16 0 4 glibc-locales-2.8.90-alt3 D: 8 2 15 0 4 glibc-nss-2.8.90-alt3 D: 9 2 12 0 4 glibc-timezones-2.8.90-alt3 D: 10 2 11 0 4 glibc-utils-2.8.90-alt3 D: 11 2 10 0 5 iconv-2.8.90-alt3 D: 12 8 22 0 6 glibc-2.8.90-alt3 D: 13 4 19 0 7 glibc-devel-2.8.90-alt3 D: 14 1 18 0 8 glibc-devel-static-2.8.90-alt3 D: 15 4 8 0 8 gcc4.3-4.3.2-alt5 D: 16 1 4 0 2 libgfortran4.3-4.3.2-alt5 D: 17 2 3 0 3 libgfortran4.3-devel-4.3.2-alt5 D: 18 3 6 0 4 gcc4.3-fortran-4.3.2-alt5 D: 19 2 2 0 3 libstdc++4.3-4.3.2-alt5 D: 20 2 1 0 4 libstdc++4.3-devel-4.3.2-alt5 D: ========== successors only (presentation order) D: 21 3 7 0 5 gcc4.3-c++-4.3.2-alt5 Note that #succesors value is actually changed using the package index in the input list of packages (on the command line): earlier packages have higher values. This is called "successors from tsort are processed in presentation order". E.g. when choosing to upgrade between cpp4.3, libgcc4.3, and libgfortran4.3, cpp4.3 gets upgraded first. (The collation is probably due to using shell glob on the command line.) The problem is that, in cpp4.3 %post-script, some pthread-dependent code might be called, and pthread shared library is simply mssing at that point (after glibc-core upgrade and before glibc-pthread install). New order is: D: ========== tsorting packages (order, #predecessors, #succesors, tree, depth) D: 0 0 1 0 0 glibc-preinstall-2.8.90-alt3 D: 1 1 17 0 1 glibc-core-2.8.90-alt3 D: 2 1 3 0 2 libgcc4.3-4.3.2-alt5 D: 3 2 8 0 3 glibc-pthread-2.8.90-alt3 D: 4 2 2 0 4 glibc-gconv-modules-2.8.90-alt3 D: 5 2 2 0 4 glibc-nss-2.8.90-alt3 D: 6 2 1 0 5 iconv-2.8.90-alt3 D: 7 2 1 0 4 glibc-locales-2.8.90-alt3 D: 8 2 1 0 4 glibc-timezones-2.8.90-alt3 D: 9 2 1 0 4 glibc-utils-2.8.90-alt3 D: 10 8 1 0 5 glibc-2.8.90-alt3 D: 11 4 4 0 6 glibc-devel-2.8.90-alt3 D: 12 2 1 0 3 libstdc++4.3-4.3.2-alt5 D: 13 2 1 0 4 libstdc++4.3-devel-4.3.2-alt5 D: 14 1 1 0 2 cpp4.3-4.3.2-alt5 D: 15 4 2 0 3 gcc4.3-4.3.2-alt5 D: 16 1 1 0 2 libgfortran4.3-4.3.2-alt5 D: 17 2 1 0 3 libgfortran4.3-devel-4.3.2-alt5 D: ========== successors only (presentation order) D: 18 2 0 0 4 glibc-core-debug-2.8.90-alt3 D: 19 1 0 0 7 glibc-devel-static-2.8.90-alt3 D: 20 3 0 0 4 gcc4.3-fortran-4.3.2-alt5 D: 21 3 0 0 4 gcc4.3-c++-4.3.2-alt5 Note that #succesors now indicates the number of immediate successors; libgcc4.3 now has 3 immediate successors (glibc-pthread, gcc4.3, and libstdc++4.3), while cpp4.3 and libgfortran4.3 have only one immediate successor. Also removed tools/rpmsort.c. > The are various serial representations of a partially ordered set. > > The default is what I call "chainsaw", always emit the node that has > the most children. The "chainsaw" heuristic tries to emit nodes that > are depended upon as early as possible to localize interactions > amongst packages, but really should be > Always emit the node of the largest sub-tree. > rather than the number of immediate children. I call this "buzzsaw". > > Anaconda has the constraint of changing cd's during install. So > "presentation" ordering preserves the arrival ordering into a > transaction set. Too bad that "presentation" ordering is often > incorrect because of no loop analysis first. https://lists.dulug.duke.edu/pipermail/rpm-devel/2005-June/000468.html
2008-11-10 05:21:23 +03:00
EXTRA_PROGRAMS = rpminject
2002-03-25 23:16:26 +03:00
#myLDFLAGS= -L$(top_builddir)/build -L$(top_builddir)/lib \
2002-03-26 00:51:30 +03:00
# -L$(top_builddir)/rpmio
2002-03-25 23:16:26 +03:00
2003-11-25 00:00:45 +03:00
LDADD = \
2002-03-25 23:16:26 +03:00
$(top_builddir)/build/librpmbuild.la \
$(top_builddir)/lib/librpm.la \
$(top_builddir)/rpmdb/librpmdb.la \
$(top_builddir)/rpmio/librpmio.la \
2002-12-09 17:05:00 +03:00
@LIBINTL@
2002-03-25 23:16:26 +03:00
noinst_PROGRAMS = \
dump dumpdb rpmarchive rpmheader rpmlead rpmsignature setcmp.static
2002-03-25 23:16:26 +03:00
pkgbindir = @RPMCONFIGDIR@
pkgbin_PROGRAMS = javadeps filesize dump_ld_config relative pdeath_execute mkset setcmp
bin_PROGRAMS = rpmvercmp rpmevrcmp
2002-03-25 23:16:26 +03:00
2003-11-24 23:44:29 +03:00
javadeps_SOURCES = javadeps.c
2002-03-25 23:16:26 +03:00
2003-11-24 23:44:29 +03:00
filesize_SOURCES = filesize.c
2003-11-25 00:00:45 +03:00
filesize_LDADD =
2002-03-26 00:51:30 +03:00
2003-11-24 23:44:29 +03:00
relative_SOURCES = relative.c
2003-11-25 00:00:45 +03:00
relative_LDADD =
2002-03-26 00:51:30 +03:00
2006-01-09 23:55:49 +03:00
dump_ld_config_SOURCES = dump_ld_config.c
dump_ld_config_LDADD =
2003-11-24 23:44:29 +03:00
pdeath_execute_SOURCES = pdeath_execute.c
2003-11-25 00:00:45 +03:00
pdeath_execute_LDADD =
2002-03-26 00:51:30 +03:00
mkset_SOURCES = mkset.c
setcmp_SOURCES = setcmp.c
setcmp_static_SOURCES = setcmp.c
setcmp_static_LDADD = @LDFLAGS_STATIC@ $(LDADD)
rpmvercmp_SOURCES = rpmvercmp.c
rpmevrcmp_SOURCES = rpmevrcmp.c
$(PROGRAMS): $(LDADD)
2002-03-25 23:16:26 +03:00
gnash.o: gnash.c
$(COMPILE) -o $@ -c gnash.c
gnash: gnash.o
2003-11-25 00:00:45 +03:00
$(LINK) -all-static -o $@ gnash.o $(LDADD)
2002-03-25 23:16:26 +03:00