File: README.source

package info (click to toggle)
rakudo 2016.12-1
  • links: PTS, VCS
  • area: main
  • in suites: stretch
  • size: 19,200 kB
  • ctags: 1,323
  • sloc: perl: 45,091; java: 2,524; ansic: 1,761; cpp: 152; sh: 17; makefile: 15
file content (67 lines) | stat: -rw-r--r-- 5,092 bytes parent folder | download
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
Updating the package
--------------------

Please make sure that moarvm and nqp are the most recent available
version to build rakudo. The versions should be identical.

You can run "perl debian/update-control.pl" so that this build-time
dependency requirements are added to control file. (this requires cme
and libconfig-model-dpkg-perl)

Why the strict runtime dependency on nqp ?
------------------------------------------

rakudo insists on using the exact version of nqp that was used for build.
So rakudo package has a dependency like (nqp = 1.2.3-1).

If nqp version does not match, rakudo bails out with something like:
$ perl6 -e 'say "Hello";'
Missing or wrong version of dependency 'gen/parrot/stage2/QRegex.nqp'
current instr.: '' pc 16152 (src/gen/perl6-pod.pir:6351) (src/Perl6/Pod.nqp:499)
called from Sub '' pc 1866 (gen/parrot/stage2/module_loader.pir:856) (src/vm/parrot/ModuleLoader.nqp:73)
called from Sub '' pc 1894 (gen/parrot/stage2/module_loader.pir:865) (src/vm/parrot/ModuleLoader.nqp:55)
called from Sub 'load_module' pc 1619 (gen/parrot/stage2/module_loader.pir:741) (src/vm/parrot/ModuleLoader.nqp:52)
called from Sub '' pc 196787 (src/gen/perl6-actions.pir:77528) (src/Perl6/Actions.nqp:7469)
called from Sub '' pc 1866 (gen/parrot/stage2/module_loader.pir:856) (src/vm/parrot/ModuleLoader.nqp:73)
called from Sub '' pc 1894 (gen/parrot/stage2/module_loader.pir:865) (src/vm/parrot/ModuleLoader.nqp:55)
called from Sub 'load_module' pc 1619 (gen/parrot/stage2/module_loader.pir:741) (src/vm/parrot/ModuleLoader.nqp:52)
called from Sub '' pc 367287 (src/gen/perl6-grammar.pir:127329) (src/Perl6/Grammar.nqp:4463)
called from Sub '' pc 1866 (gen/parrot/stage2/module_loader.pir:856) (src/vm/parrot/ModuleLoader.nqp:73)
called from Sub '' pc 1894 (gen/parrot/stage2/module_loader.pir:865) (src/vm/parrot/ModuleLoader.nqp:55)
called from Sub 'load_module' pc 1619 (gen/parrot/stage2/module_loader.pir:741) (src/vm/parrot/ModuleLoader.nqp:52)
called from Sub '' pc 758 (src/gen/perl6.pir:285) (gen/parrot/main.nqp:54)

(02:03:43 PM) timotimo: right, when nqp changes, rakudo immediately has to be rebuilt to go with the new nqp
(02:04:42 PM) domidumont: timotimo: I get that, but I did not change nqp. I just rebuilt it
(02:04:56 PM) [ptc]: my guess is that if one of the "supporting" packages needs a packaging fix, then all above need to be rebuilt and repackaged as well
(02:05:29 PM) domidumont: [ptc]: usually, not if the change is backward compatible
(02:06:28 PM) moritz: rakudo depends on exact versions of serialization contexts in nqp
(02:06:47 PM) moritz: so even if your fix adds a single object that's not exposed to the outside world, you need a rakudo rebuild
(02:07:23 PM) [ptc]: domidumont: I only meant in the Rakudo stack, since it looks like if one needs to rebuild nqp, then rakudo needs to be rebuilt too
(02:07:34 PM) domidumont: moritz: that sounds reasonable. But why impose a rebuild if the code does not change ?
(02:08:00 PM) moritz: domidumont: that's another nasty thing (more)
(02:08:06 PM) [ptc]: domidumont: however, that's how it *looks*, there are probably other considerations which mean that one can avoid rebuilds in some situations
(02:08:15 PM) timotimo: domidumont: ah, well, that's a change in rakudo's eyes :\
(02:08:27 PM) moritz: domidumont: nqp and rakudo identify serialization contexts via hashes
(02:08:51 PM) moritz: domidumont: now nqp is self-hosting, which means it must take care not to confuse the SC of the host and of the source when compiling itself
(02:09:26 PM) moritz: domidumont: which is why it introduces timestamps into these SCs, to avoid collision
(02:10:02 PM) moritz: domidumont, jnthn: I wonder if we could use command-line-supplyable identifiers instead of timestamps to distinguis the stages at the various builds
(02:10:24 PM) moritz: then a rebuild without a code change should get an SC with the same hash
(02:10:29 PM) timotimo: that could also give us shorter identifiers
(02:10:32 PM) timotimo: i'd like that
(02:10:40 PM) timotimo: save a tiny bit more ram and disk space
(02:12:18 PM) domidumont: Or the hash could be based on the actual source code (a bit like the code signatures computed by cons or scons)
(02:12:36 PM) timotimo: that would break the compiler vs compilee thing again
(02:13:00 PM) timotimo: because we always build the stage2 with the same code we've built the stage1 from
(02:13:24 PM) ***domidumont light bulb went on
(02:13:46 PM) moritz: domidumont: no
(02:13:55 PM) moritz: domidumont: because stage 1 and stage 2 have the same source code
(02:15:02 PM) domidumont: can the hash be salted with stage1 and then stage2 ?
(02:16:11 PM) moritz: something like that, yes
(02:16:25 PM) moritz: that's what I meant with command-line-supplyable identifiers
(02:16:52 PM) domidumont: ah ok.
(02:17:21 PM) timotimo: those identifiers could very well have - for example - the git commit identifier (plus a random string if the commit is "dirty")

So it looks like hairy dependency should be improved.

 -- Dominique Dumont <dod@debian.org>, Mon, 25 Apr 2016 13:55:21 +0200