-
Notifications
You must be signed in to change notification settings - Fork 0
/
README.Linden
executable file
·548 lines (458 loc) · 21.6 KB
/
README.Linden
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
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
0. Pre-Checkin Checklist
Performed from top of repo, default branch, head:
[ ] Is tag 'current' at or near head of 'vendor'?
hg heads
hg tags
[ ] Expected differences between vendor and default? Very little
of the original source should be modified.
hg diff -rcurrent DirectFB
hg diff -rcurrent SDL
[ ] Are the 'vendor' and 'default' branch source directories
'DirectFB'/'SDL' and not '*-<version>'?
[ ] Have you reverted/blocked checkin of files modified by config
such as 'DirectFB/include/directfb_build.h' and
'DirectFB/lib/fusion/build.h'?
[ ] Did DirectFB configuration find the packages and build
correctly with them?
checking for jpeg_destroy_decompress in -ljpeg... yes
checking jpeglib.h usability... yes
checking jpeglib.h presence... yes
checking for jpeglib.h... yes
checking for gzsetparams in -lz... yes
checking zlib.h usability... yes
checking zlib.h presence... yes
checking for zlib.h... yes
checking for LIBPNG... yes
checking for LIBTIFF... no
Building Image Provider Modules:
GIF yes
JPEG yes -ljpeg <<< (*could* be from packages)
PNG yes -I/ngi-persist/monty/3P/FINAL/3p-sdl-update/stage/packages/include/libpng16 -lpng16 -lz -lm
[ ] Did SDL configuration correctly find DirectFB?
checking for getpagesize... yes
checking for directfb-config... /ngi-persist/monty/3P/FINAL/3p-sdl-update/stage/bin//directfb-config
checking directfb.h usability... yes
checking directfb.h presence... yes
checking for directfb.h... yes
checking for DirectFB 0.9.15 support... yes
checking for PlayStation 2 GS support... no
[ ] Verified that the DirectFB and SDL libraries do not
re-export zlib and libpng symbols:
$ nm stage/lib/release/*.so | grep flate
001038a0 t deflate
00103740 t deflateBound
00104eb0 t deflateCopy
00104a20 t deflateEnd
00104b20 t deflateInit2_
etc.
$ nm stage/lib/release/*.so | grep png
$
[ ] Verified library strings for zlib and libpng are as expected?
$ strings stage/lib/release/*.{so,a} | grep 1\\.[0-9]\\.
libdirectfb-1.7.so.1
libfusion-1.7.so.1
libdirect-1.7.so.1
lib++dfb-1.7.so.1
libdirectfb-1.7.so.1
libfusion-1.7.so.1
libdirect-1.7.so.1
libSDL-1.2.so.0
libdirect-1.7.so.1
1.7.1
libdirect-1.7.so.1
libfusion-1.7.so.1
libdirectfb-1.7.so.1
~~~~~~~~~~~~~~~~~~~~~~~~~~| DirectFB 1.7.1 |~~~~~~~~~~~~~~~~~~~~~~~~~~
/ngi-persist/monty/3P/FINAL/3p-sdl-update/stage/lib/release/libdirectfb-1.7.so.1
/ngi-persist/monty/3P/FINAL/3p-sdl-update/stage/share/directfb-1.7.1/cursor.dat
Core/WindowStack: `/ngi-persist/monty/3P/FINAL/3p-sdl-update/stage/share/directfb-1.7.1/cursor.dat` could not be opened!
DirectFB version 1.7.1
1.2.8
deflate 1.2.8 Copyright 1995-2013 Jean-loup Gailly and Mark Adler
inflate 1.2.8 Copyright 1995-2013 Mark Adler
libdirect-1.7.so.1
libfusion-1.7.so.1
1.7.1
~~~~~~~~~~~~~~~~~~~~~~~~~~| DirectFB 1.7.1 |~~~~~~~~~~~~~~~~~~~~~~~~~~
/ngi-persist/monty/3P/FINAL/3p-sdl-update/stage/lib/release/libdirectfb-1.7.so.1
/ngi-persist/monty/3P/FINAL/3p-sdl-update/stage/share/directfb-1.7.1/cursor.dat
Core/WindowStack: `/ngi-persist/monty/3P/FINAL/3p-sdl-update/stage/share/directfb-1.7.1/cursor.dat` could not be opened!
DirectFB version 1.7.1
[ ] Verified that build products use the correct version of zlib
and libpng and do not reference shared libraries:
$ ldd stage/bin/*
dfbdump:
linux-gate.so.1 => (0xf77d7000)
libdirectfb-1.7.so.1 => /ngi-persist/monty/3P/3p-sdl-update/stage/lib/release/libdirectfb-1.7.so.1 (0xf7685000)
libfusion-1.7.so.1 => /ngi-persist/monty/3P/3p-sdl-update/stage/lib/release/libfusion-1.7.so.1 (0xf7675000)
libdirect-1.7.so.1 => /ngi-persist/monty/3P/3p-sdl-update/stage/lib/release/libdirect-1.7.so.1 (0xf764f000)
libdl.so.2 => /lib32/libdl.so.2 (0xf7637000)
librt.so.1 => /lib32/librt.so.1 (0xf762e000)
libpthread.so.0 => /lib32/libpthread.so.0 (0xf7614000)
libc.so.6 => /lib32/libc.so.6 (0xf74cd000)
libstdc++.so.6 => /usr/lib32/libstdc++.so.6 (0xf73e5000)
libm.so.6 => /lib32/libm.so.6 (0xf73bf000)
libgcc_s.so.1 => /usr/lib32/libgcc_s.so.1 (0xf73a2000)
/lib/ld-linux.so.2 (0xf77d8000)
dfbdumpinput:
etc...
$ ldd stage/lib/release/*.so*
lib++dfb-1.7.so.1:
linux-gate.so.1 => (0xf7779000)
libdirectfb-1.7.so.1 => /ngi-persist/monty/3P/3p-sdl-update/stage/lib/release/libdirectfb-1.7.so.1 (0xf7607000)
libfusion-1.7.so.1 => /ngi-persist/monty/3P/3p-sdl-update/stage/lib/release/libfusion-1.7.so.1 (0xf75f7000)
libdirect-1.7.so.1 => /ngi-persist/monty/3P/3p-sdl-update/stage/lib/release/libdirect-1.7.so.1 (0xf75d1000)
libdl.so.2 => /lib32/libdl.so.2 (0xf75b9000)
librt.so.1 => /lib32/librt.so.1 (0xf75b0000)
libpthread.so.0 => /lib32/libpthread.so.0 (0xf7596000)
libstdc++.so.6 => /usr/lib32/libstdc++.so.6 (0xf74ae000)
libm.so.6 => /lib32/libm.so.6 (0xf7488000)
libc.so.6 => /lib32/libc.so.6 (0xf7341000)
libgcc_s.so.1 => /usr/lib32/libgcc_s.so.1 (0xf7324000)
/lib/ld-linux.so.2 (0xf777a000)
lib++dfb-1.7.so.1.0.0:
etc...
[ ] Verified that build products use the correct version of
libpng and zlib:
$ strings stage/lib/release/directfb-1.7-1/interfaces/IDirectFBImageProvider/li*.so | grep 1\\.[0-9]\\.
libdirect-1.7.so.1
libdirectfb-1.7.so.1
libdirect-1.7.so.1
libdirectfb-1.7.so.1
libdirect-1.7.so.1
libdirectfb-1.7.so.1
libdirect-1.7.so.1
libdirectfb-1.7.so.1
libdirect-1.7.so.1
libdirectfb-1.7.so.1
libdirect-1.7.so.1
libdirectfb-1.7.so.1
1.6.8
libpng version 1.6.8 - December 19, 2013
libpng version 1.6.8 - December 19, 2013
1.2.8
deflate 1.2.8 Copyright 1995-2013 Jean-loup Gailly and Mark Adler
inflate 1.2.8 Copyright 1995-2013 Mark Adler
libdirect-1.7.so.1
libdirectfb-1.7.so.1
1. Introduction
Builds of DirectFB library from directfb.org and SDL from
libsdl.org.
Repo structure *now* mostly follows standard conventions (see
section at end).
Prior to 1.7.1/1.2.15, repo didn't follow standard convention and
each release was disconnected from previous releases.
Modifications to branch 'default' were re-implemented on every
update.
How much of these libraries is actually used is unknown. The
DirectFB library is plugin/module-oriented but we are not
packaging any of the modules. It may be doing little more than
empty link-resolution. A build of SDL without directfb support
was incorporated into a viewer build and it did appear to function
with window resizing, etc. working. It may be that some problem
lurks or the disabling of features like real fullscreen mode have
made DirectFB unnecessary (for the moment).
1.1 Futures
The 1.2 SDL package is well into legacy status. The 2.0 re-design
appears to offer some improvements in keyboard/IM handling and
fullscreen mode that we could use. The keyboard side will
probably require some work.
DirectFB also consumes libpng but from the system, not from our
packages. That's something we might want to change *if* it
actually matters. It may be used only by DirectFB plugins.
2. Modifications
Essential modifications to DirectFB/SDL distributions.
2.1 Updating Libraries
Two unrelated libraries reside in the repo and I've found that 'hg
addremove' does a better job if they are updated together as one
large checkin.
2.2 Building
Getting these to build with zlib and libpng packages was a little
tedious. Any updates should be very careful about correct
compilation and linkage. Libpng APIs change from release to
release and mixing is likely unreliable.
(Not certain if libpng actually matters here. It appears that the
only code that references it isn't packaged.)
Unit tests aren't really provided by the libraries. There are
basic test and example programs but building and running these
requires a screen as well as additional libraries.
3. Source Origin
DirectFB 1.7.1:
http://directfb.org/downloads/Core/DirectFB-1.7/DirectFB-1.7.1.tar.gz
SDL 1.2.15:
http://www.libsdl.org/release/SDL-1.2.15.tar.gz
4. Package Contents
Common:
* include/directfb/*
* include/directfb-internal/*
* include/SDL/*
Linux (debug and release, archive and shared):
* lib/release/lib++dfb.a
* lib/release/lib++dfb.so
* lib/release/lib++dfb-1.7.so.1
* lib/release/lib++dfb-1.7.so.1.0.0
* lib/release/libdirect.a
* lib/release/libdirect.so
* lib/release/libdirect-1.7.so.1
* lib/release/libdirect-1.7.so.1.0.0
* lib/release/libdirectfb.a
* lib/release/libdirectfb.so
* lib/release/libdirectfb-1.7.so.1
* lib/release/libdirectfb-1.7.so.1.0.0
* lib/release/libfusion.a
* lib/release/libfusion.so
* lib/release/libfusion-1.7.so.1
* lib/release/libfusion-1.7.so.1.0.0
* lib/release/libSDLmain.a
* lib/release/libSDL.a
* lib/release/libSDL.so
* lib/release/libSDL-1.2.so.0
* lib/release/libSDL-1.2.so.0.11.4
* lib/debug/lib++dfb.a
* lib/debug/lib++dfb.so
* lib/debug/lib++dfb-1.7.so.1
* lib/debug/lib++dfb-1.7.so.1.0.0
* lib/debug/libdirect.a
* lib/debug/libdirect.so
* lib/debug/libdirect-1.7.so.1
* lib/debug/libdirect-1.7.so.1.0.0
* lib/debug/libdirectfb.a
* lib/debug/libdirectfb.so
* lib/debug/libdirectfb-1.7.so.1
* lib/debug/libdirectfb-1.7.so.1.0.0
* lib/debug/libfusion.a
* lib/debug/libfusion.so
* lib/debug/libfusion-1.7.so.1
* lib/debug/libfusion-1.7.so.1.0.0
* lib/debug/libSDLmain.a
* lib/debug/libSDL.a
* lib/debug/libSDL.so
* lib/debug/libSDL-1.2.so.0
* lib/debug/libSDL-1.2.so.0.11.4
===================================================================
Third-Party Library Repo Structure
Introduction
We want to have a way to capture local modifications to a third-party
open-source project, such as libcurl, without needing write access to
their public repository. We want to be able to carry forward such
modifications to newer versions of the public project. All this
should be independent of the organizational decision as to whether
it's even desirable to try to submit our local modifications upstream.
Fortunately, the Subversion folks articulated a process years ago that
addresses this very requirement. They call it "Vendor Branches." The
same tactic, suitably adapted, works with Mercurial too.
The essence of the idea is that we capture and tag a particular
snapshot of the open-source project. We develop our local
modifications to that, and the repository tip incorporates them. But
when we want to update to a newer version of the public project, we
bring it into the repository in such a way that we can discover the
changes from the original snapshot and the new one -- and then have
Mercurial apply those deltas to the ''combined'' source.
The following material is adapted from
http://svnbook.red-bean.com/en/1.1/ch07s05.html, the Red Bean
Subversion book, but recast for Mercurial. The Linden source for this
material is an internal wiki. There may be superceding documentation
on the public wiki when you read this. We recommend searching there
for updates to conventions below. And note that each particular
library may implement variations of this scheme.
General Vendor Branch Management Procedure
Managing vendor branches generally works like this. You create a
named branch ("vendor") to store the vendor source snapshots. Then
you import the third party code into that branch. Your modified
branch (named "default") is based on "vendor". You always make your
local changes to the default branch. With each new release of the
code you are tracking you bring it into the "vendor" branch and merge
the changes into "default", resolving whatever conflicts occur between
your local changes and the upstream changes.
Perhaps an example will help to clarify this algorithm. We'll use a
scenario where your development team is creating a calculator program
that links against a third-party complex number arithmetic library,
libcomplex. We'll construct a repository specifically for our
locally-modified version of that library. To begin, we must
initialize our repository and create at least one file in our
"default" branch.
$ hg init ourcomplex
$ cd ourcomplex
$ touch README.txt
$ hg commit README.txt
Now we can create the vendor branch and do the import of the first
vendor drop. We'll call our vendor branch "vendor", and each
successive code drop will be tagged "current".
$ hg branch vendor
$ tar -xjf ../libcomplex-1.0.tar.bz2
$ mv libcomplex-1.0 libcomplex
$ hg addremove
$ hg commit -m "1.0 source drop"
$ hg tag -r tip current
$ hg tag -r current 1.0
We now have the current version of the libcomplex source code in
branch "vendor", tagged "current" and in a non-version-specific source
code subdirectory ("libcomplex"). Next, we merge it into the default
branch. It is in the default branch that we will make our
customizations.
$ hg update default
$ hg merge vendor
$ hg commit -m "initial: 1.0"
We get to work customizing the libcomplex code. Before we know it,
our modified version of libcomplex is now completely integrated into
our calculator program.
A few weeks later, the developers of libcomplex release a new version
of their library, version 1.1, which contains some features and
functionality that we really want. We'd like to upgrade to this new
version, but without losing the customizations we made to the existing
version. What we essentially would like to do is to replace our
current baseline version of libcomplex 1.0 with a copy of libcomplex
1.1, and then have Mercurial re-apply the custom modifications we
previously made to that library to the new version. But we actually
approach the problem from the other direction, applying the changes
made to libcomplex between versions 1.0 and 1.1 to our modified copy
of it.
To perform this upgrade, we update our repository to our vendor
branch, and update the "current" tag with the new libcomplex 1.1
source code. We quite literally replace the existing files with the
new files, clearing out the whole tree and exploding the libcomplex
1.1 release tarball in its place. The goal here is to make the tip of
our vendor branch contain only the libcomplex 1.1 code, and to ensure
that all that code is under version control. Oh, and we want to do
this with as little version control history disturbance as possible.
$ hg update vendor
$ rm -rf *
$ tar -xjf ../libcomplex-1.1.tar.bz2
$ mv libcomplex-1.1 libcomplex
$ hg addremove -s 60
$ # Additional 'hg add' and 'hg rm' commands if needed
$ hg commit -m "1.1 source drop"
After unpacking the 1.1 tarball, hg status will show files with local
modifications as well as, perhaps, some unversioned or missing files.
If we did what we were supposed to do, the unversioned files are only
those new files introduced in the 1.1 release of libcomplex. The
missing files are files that were in 1.0 but not in 1.1. The 'hg
addremove' command deals with both, and more: the '-s 60' switch
directs Mercurial to compare added files to deleted files, recognizing
any file at least 60% similar as a move/rename.
For simple or stable libraries, the 'hg addremove' command should be
reliable. For more complicated libraries subject to refactoring or
large gaps of time between updates (e.g. libcurl), it can get a little
lost trying to match files in the old release with files in the new
release. Pay attention to the output of the command or better still,
do dry runs. Files erroneously moved can be excluded with the '-X'
option and then dealt with individually with 'hg add' and 'hg rm'
commands after 'hg addremove'. (The readme file in the curl library
should document a particularly challenging case.)
The 'addremove' process doesn't have to be perfect. Recreating the
evolution of the upstream source tree isn't universally practical.
But we'd like to capture movement of files in the vendor branch that
are modified in the default branch. If achieving that becomes too
tedious, then re-implementation of the default branch edit in a new
file is fine. Just note it here for the next developer.
Finally, once our current working copy contains only the libcomplex
1.1 code, we commit the changes we made to get it looking that way.
Our current vendor branch now contains the new vendor drop. We move
the 'current' tag to the new version (in the same way we previously
tagged the version 1.0 vendor drop), and then merge the differences
between the version 1.0 and version 1.1 into our default branch.
$ hg tag -f -r tip current
$ hg tag -r current 1.1
$ hg update default
$ hg merge vendor
# resolve all the conflicts between their changes and our changes
# if you will have conflicts in .hgtags, simply take *all* lines
...
$ hg commit -m "update with 1.1"
Any additional work needed to get the merged library working can
now be done on the default branch.
Revision Tags
We don't currently make use of Mercurial tags in the build and release
process for 3rd-party libraries. But we would like to establish a
convention to document update and release points. The tags we would
like to establish are:
* 'current' Points to a succession of vendor releases checked into
the 'vendor' branch. Will almost always be at or close to branch
head.
* '<version>' Tag on the 'vendor' branch pointing to a verbatim
checkin of a 3rd-party's <version> release. Example: '7.21.1' for
a particular version of libcurl we have used.
* Release-type tags on the default branch aren't as useful given how
Mercurial handles tags and how autobuild works.
Schematic of a Third-Party Repository
Below is the output of the 'hg glog' command showing a library project
going through an initial 1.0 release and an update from the vendor to
1.1. Significant revisions in the repository lifecycle are as
follows:
0 Creation of the repo with an initial file.
1 1.0 code drop on branch 'vendor'
4 Merge of 1.0 code onto branch 'default'
5 Modifications to library we wish to keep over time. Released.
6 1.1 code drop on branch 'vendor'
9 Merge of 1.1 code onto branch 'default'
10 Fixes to merge yielding production 1.1 library. Released.
@ changeset: 10:888229641f6e
| tag: tip
| user: Monty Brandenberg <[email protected]>
| date: Wed Oct 30 13:35:51 2013 -0400
| summary: Work to get 1.1 merge working. Release.
|
o changeset: 9:925ccdf09f50
|\ parent: 5:83c5775c23dc
| | parent: 8:977001a08e48
| | user: Monty Brandenberg <[email protected]>
| | date: Wed Oct 30 13:35:20 2013 -0400
| | summary: update with 1.1
| |
| o changeset: 8:977001a08e48
| | branch: vendor
| | user: Monty Brandenberg <[email protected]>
| | date: Wed Oct 30 13:33:49 2013 -0400
| | summary: Added tag 1.1 for changeset 5f6cb89add91
| |
| o changeset: 7:59bce0f6d12f
| | branch: vendor
| | user: Monty Brandenberg <[email protected]>
| | date: Wed Oct 30 13:33:41 2013 -0400
| | summary: Added tag current for changeset 5f6cb89add91
| |
| o changeset: 6:5f6cb89add91
| | branch: vendor
| | tag: current
| | tag: 1.1
| | parent: 3:8525ad934ecd
| | user: Monty Brandenberg <[email protected]>
| | date: Wed Oct 30 13:33:29 2013 -0400
| | summary: 1.1 source drop
| |
o | changeset: 5:83c5775c23dc
| | tag: 1.0
| | user: Monty Brandenberg <[email protected]>
| | date: Wed Oct 30 13:32:31 2013 -0400
| | summary: Linden-specific changes to the library. Release
| |
o | changeset: 4:bccb736585f4
|\| parent: 0:400e4516c406
| | parent: 3:8525ad934ecd
| | user: Monty Brandenberg <[email protected]>
| | date: Wed Oct 30 13:31:40 2013 -0400
| | summary: initial: 1.0
| |
| o changeset: 3:8525ad934ecd
| | branch: vendor
| | user: Monty Brandenberg <[email protected]>
| | date: Wed Oct 30 13:30:21 2013 -0400
| | summary: Added tag 1.0 for changeset 8ac3828d03bb
| |
| o changeset: 2:7aa1a1cb62d9
| | branch: vendor
| | user: Monty Brandenberg <[email protected]>
| | date: Wed Oct 30 13:30:14 2013 -0400
| | summary: Added tag current for changeset 8ac3828d03bb
| |
| o changeset: 1:8ac3828d03bb
|/ branch: vendor
| tag: 1.0
| user: Monty Brandenberg <[email protected]>
| date: Wed Oct 30 13:30:09 2013 -0400
| summary: 1.0 source drop
|
o changeset: 0:400e4516c406
user: Monty Brandenberg <[email protected]>
date: Wed Oct 30 13:29:16 2013 -0400
summary: Created repo with initial readme file