~contact-philipashmore/meta-treedb/master

« back to all changes in this revision

Viewing changes to makefile

  • Committer: Philip Ashmore
  • Date: 2011-12-20 08:29:12 UTC
  • Revision ID: git-v1:0dd07accda30d5973be6f882fff1b713469b0d1a
Version 1.4.0-01

* Added a long description for debian/control

* Added a v3c-meta-comet man page

* Lots of fiddly changes to pass Debians "lintian" checks
  All the DEBIAN*_REQUIRES have changed to DEBIAN*_DEPENDS.
  Since they go into the Build-Depends and Depends fields of the
  debian/control(.in) file, this makes more sense.

Show diffs side-by-side

added added

removed removed

Lines of Context:
3
3
 
4
4
# One source for the package name and version information - here.
5
5
export package_name=meta-treedb
6
 
export package_description=meta-treedb implements on-disk memory using meta-data
 
6
export package_description=on-disk memory library using meta-data
 
7
define package_long_description
 
8
 meta-treedb can implement malloc functionality, and much more!
 
9
 Need a heap that allocates of a fixed size chunk of memory? No problem.
 
10
 But where treedb comes into its own is when it comes to allocating from a
 
11
 mmap()ed disk file - the memory becomes persistent.
 
12
 .
 
13
 If you follow the tests/examples, you too can store dictionaries, trees, lists
 
14
 or whatever you can think of in disk-based memory, just an open() and mmap()
 
15
 away.
 
16
 .
 
17
 Meta-treedb comes with an AVL tree, doubly-linked-list and
 
18
 variable-entry-sized-array implementations for you to use in your data
 
19
 structures.
 
20
 .
 
21
 So, what distinguishes meta-treedb from treedb?
 
22
 * "class" interfaces for treedb collections
 
23
 .  These are vtables (virtual function tables) that implement the interface.
 
24
 * faster compiles - only the "class" interfaces are visible to client code
 
25
 .  This is at the expense of a small performance hit.
 
26
 * the ability to use implementations that were developed after client code was
 
27
 .  compiled.
 
28
 .  This feature hasn't been fully fleshed out yet, as it would require a
 
29
 .  plug-in system such as that provided by v3c-dcom, but it's coming soon.
 
30
endef
 
31
export package_long_description
 
32
 
7
33
# The package version number, (as distinct from shared library version)
8
34
# An odd micro number indicates in-progress development, (eg. from GIT)
9
35
# An even micro number indicates a released version.
10
36
export package_major_version=1
11
 
export package_minor_version=3
 
37
export package_minor_version=4
12
38
export package_micro_version=0
13
 
export package_version=$(package_major_version).$(package_minor_version).$(package_micro_version)-03
 
39
export package_version=$(package_major_version).$(package_minor_version).$(package_micro_version)-01
14
40
# increase the interface age by 2 for each release;
15
41
# if the API changes, set to 0
16
42
export package_interface_age=0
17
43
 
18
44
# This is the version clients may need to re-code for.
19
45
export package_next_major_version=1
20
 
export package_next_minor_version=4
 
46
export package_next_minor_version=5
21
47
export package_next_micro_version=0
22
48
export package_next_version=$(package_next_major_version).$(package_next_minor_version).$(package_next_micro_version)
23
49