Re: [racket-dev] advice on the 6.x build system.
At Fri, 17 Oct 2014 17:56:51 +0200, David Bremner wrote:
Matthew Flatt mfl...@cs.utah.edu writes:
Meanwhile, I haven't answered your original question. Can you remind me
of the specific steps that I'd need to follow to try the script that
you sent before?
With your indulgence, I'll just answer this part now. I have re-included
the Makefile as an attachment, since make is fussy about whitespace.
Save the attached file to e.g. /tmp/test.mk
In a recent checkout of the release branch,
% make -f /tmp/test.mk build-indep-stamp
the resulting build of racket will be in test-dest, in the top level
directory of racket. For me, test-dest/usr/bin only has racket and raco
in it.
The problem is that `make install` works with a configuration whose
paths are based on DESTDIR, but as its final act it rewrites
config.rktd and other files to strip away DESTDIR. That rewrite tells
the later use of `raco pkg install` to put binaries in the DESTDIRless
path (i.e., /usr/bin), and so on. It's a kind of bad luck that `raco
pkg install` runs at all, since it could depend on the DESTDIRless pass
in any number of ways, such as an embedded path in a shared library.
If you really want to go this way, I could extend the makefile to let
you supply a command that runs before the path-fixup step of `make
install`. Then, your test.mk would look more like this:
build-arch-stamp: ${base_build_dir}/Makefile
$(MAKE) -C ${base_build_dir}
$(MAKE) -C ${base_build_dir} DESTDIR=${destdir} install \
FINAL_PREP_CMD=cd $(CURDIR) \
$(MAKE) RACKET=''${PRERACKET}'' \
local-source-catalog \
${PRERACKET} -N raco -l- \
pkg install ${raco_args} \
main-distribution racket-lib
touch $@
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] advice on the 6.x build system.
At Fri, 17 Oct 2014 07:43:17 +0200, David Bremner wrote: Matthew Flatt mfl...@cs.utah.edu writes: That said, is there a particular reason that basing the build on the git repo would be better? One reason is that I need I need to track from release to release the files that are removed from the racket source by debian for licensing-related reasons. Currently this looks like: ╰─ (git)-[new-master]-% git diff --stat dfsg..upstream .../drdr/static/jquery-1.6.2.min.js| 18 + .../resources/js/libs/gumby.min.js |1 + .../js/libs/jquery-1.9.1.min.js|5 + .../libs/jquery.mobile.custom.min.js |3 + .../js/libs/modernizr-2.6.2.min.js |4 + .../resources/js/plugins.js|8 + .../racket/benchmarks/common/maze.sch | 680 ++ .../racket/benchmarks/common/maze2.sch | 695 ++ .../common/psyntax-input.txt | 4296 .../benchmarks/common/typed/maze2.rktl | 772 ++ .../racket-test/tests/xml/xmltest.zip | Bin 0 - 107060 bytes Happily, none of those are the main-distribution bundles. I don't think that's a coincidence, and in any case, it should be a goal that we don't include troublesome files in the distribution. A second reason is that I want to be able to able to backport patches to older releases of racket running on Debian. This is much easier if I can just use git cherry-pick. I can see that `git cherry-pick` is more convenient than creating patch files, at least until we split the Racket repo. In the near future, when the main distribution is spread out over 60-90 repos, then it sounds less convenient. A third reason (related) is that from time to time I need to test the Debian packaging of an as yet unreleased racket version, e.g. to check if a build failure is fixed in the upcoming 6.1.1 branch. The daily snapshot builds have the same shape as a release, as do the test builds at http://pre-release.racket-lang.org/. So, I think a source build will be available when you need one. Also, you can always create your own source bundle from the git repo by using `make installer SOURCE_MODE=--source`. That begs the question of what it means to use a source distribution instead the repo, but the point is that `make installer` is likely to change shape in the near future, while the source distribution is not (so a build based on the source distribution may be a more reusable component.) You can add a FWIW in front of all of those, since you know the constraints and problems of Debian packaging better. I just worry about the mismatch between the idea of get a Racket distribution from a single git repo versus the more distributed and package-based direction that we're heading. Meanwhile, I haven't answered your original question. Can you remind me of the specific steps that I'd need to follow to try the script that you sent before? _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] advice on the 6.x build system.
Matthew Flatt mfl...@cs.utah.edu writes: Meanwhile, I haven't answered your original question. Can you remind me of the specific steps that I'd need to follow to try the script that you sent before? With your indulgence, I'll just answer this part now. I have re-included the Makefile as an attachment, since make is fussy about whitespace. Save the attached file to e.g. /tmp/test.mk In a recent checkout of the release branch, % make -f /tmp/test.mk build-indep-stamp the resulting build of racket will be in test-dest, in the top level directory of racket. For me, test-dest/usr/bin only has racket and raco in it. test.mk Description: Binary data _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] advice on the 6.x build system.
Hi David,
If I understand correctly, you're trying to base the build on a
checkout of the Racket git repository. I think it's better to base it
on a release source distribution, instead:
* The source distribution embeds a reference to a release-specific
package catalog, which effectively freezes certain packages to that
release. (Which packages and exactly how they should freeze will be
an ongoing experiment, but the source distribution will be set up
the right way, in any case).
* We plan to split up the current Racket repository into many
package-specific repositories. The current structure was intended as
a stop-gap, and it's not clear that anything like `make
local-source-catalog` will continue to exist.
That said, is there a particular reason that basing the build on the
git repo would be better?
Matthew
At Thu, 16 Oct 2014 23:23:37 +0200, David Bremner wrote:
I've been been trying to rework the debian racket packaging, and to
understand the new racket build system. I need to have the two seperate
targets, which most of the package installation is done in the the
build-indep-stamp target.
The following makefile snippet is _almost_ working, except that I'm
missing a launcher for drracket. After installing debian/tmp, running
/usr/lib/racket/gracket and (require drracket) seems to work ok to start
drracket, so I take that as indicating most of the packages / collects
are in the right place. Can anyone see what I'm doing wrong here?
I should say that I tried to make better use of the top level makefile,
but I ended up with wrong default collects paths (probably just a
different error on my part).
I tried all of this (most recently) with the current release branch
(c326c21b73356e)
destdir:=$(CURDIR)/debian/tmp
base_build_dir:=$(CURDIR)/racket/src/build
PRERACKET:=${destdir}/usr/bin/racket -X ${destdir}/usr/share/racket/collects
raco_args:=--catalog build/local/catalog --auto -i --skip-installed
${base_build_dir}/Makefile:
mkdir -p ${base_build_dir}
cd ${base_build_dir} $(CURDIR)/racket/src/configure --prefix=/usr
build-arch-stamp: ${base_build_dir}/Makefile
$(MAKE) -C ${base_build_dir}
$(MAKE) -C ${base_build_dir} DESTDIR=${destdir} install
touch $@
build-indep-stamp: build-arch-stamp
$(MAKE) RACKET=${PRERACKET} \
local-source-catalog
${PRERACKET} -N raco -l- \
pkg install ${raco_args} main-distribution racket-lib
touch $@
_
Racket Developers list:
http://lists.racket-lang.org/dev
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] advice on the 6.x build system.
Matthew Flatt mfl...@cs.utah.edu writes: That said, is there a particular reason that basing the build on the git repo would be better? One reason is that I need I need to track from release to release the files that are removed from the racket source by debian for licensing-related reasons. Currently this looks like: ╰─ (git)-[new-master]-% git diff --stat dfsg..upstream .../drdr/static/jquery-1.6.2.min.js| 18 + .../resources/js/libs/gumby.min.js |1 + .../js/libs/jquery-1.9.1.min.js|5 + .../libs/jquery.mobile.custom.min.js |3 + .../js/libs/modernizr-2.6.2.min.js |4 + .../resources/js/plugins.js|8 + .../racket/benchmarks/common/maze.sch | 680 ++ .../racket/benchmarks/common/maze2.sch | 695 ++ .../common/psyntax-input.txt | 4296 .../benchmarks/common/typed/maze2.rktl | 772 ++ .../racket-test/tests/xml/xmltest.zip | Bin 0 - 107060 bytes I used to do this by importing the tarballs on top of the git history, but since 6.0 this import creates a massive diff because of all the re-arranging that happens in tarball creating process. At this point the I the history becomes difficult to follow (or at least ugly). From our point of view, once we have to delete things, the tarballs also lose their status as an pristine work of upstream. A second reason is that I want to be able to able to backport patches to older releases of racket running on Debian. This is much easier if I can just use git cherry-pick. A third reason (related) is that from time to time I need to test the Debian packaging of an as yet unreleased racket version, e.g. to check if a build failure is fixed in the upcoming 6.1.1 branch. d _ Racket Developers list: http://lists.racket-lang.org/dev
