Download Reference Manual
The Developer's Library for D
About Wiki Forums Source Search Contact

Ticket #291 (closed enhancement: fixed)

Opened 17 years ago

Last modified 17 years ago

Installs should include lib files

Reported by: larsivi Assigned to: kris
Priority: major Milestone: 1.0
Component: Packaging Version:
Keywords: Cc: Richards@codu.org

Description

With the latest advances in lib "technology", we should start to distribute and install binary library files, instead of runtime + buildtool approach (although it should still be available for those who want, or who may have some platform we don't build for).

All installers should accomodate for this, and if necessary, the lib building scripts needs to be devised.

Change History

03/03/07 00:09:35 changed by kris

  • status changed from new to assigned.
  • milestone changed from 0.96 Beta 2 to 1.0.

03/13/07 09:53:18 changed by larsivi

  • cc set to Richards@codu.org.

What libraries should be included for the different platforms, what changes should be done to config files (sc.ini etc) for them to be used correctly? And what should the names be?

On Windows it is (I suppose) tango.lib (and usergdi32.lib), but on *nix the situation isn't necessarily as easy, as versioned libraries actually are viable.

I'd thus prefer libraries with full version names (two components) - and possibly a convention where snapshots are numbered in between, that is if latest release was 1.4, then snapshots are 1.5 until 1.6 becomes next stable. Not very important prior to 1.0 maybe. libtango.lib/so should always be symlinked to the latest installed version.

Ah, yes, I've assumed above that *nix binaries will ship with both shared and static libraries.

03/13/07 20:05:43 changed by Gregor

dsss build ; dsss install

Tada, you're done.

If you ship shared libraries (I'd highly recommend against doing this), you should be careful to set the soversion properly. The easiest way to do this is to just use DSSS ;)

03/13/07 20:13:37 changed by Gregor

A note on versioning:

Don't version your static libraries unless you create 100% incompatible versions. Like GTK+ -> GTK+2. At that point, you can simply add a version number to the static name.

Version your shared libraries very carefully: The first number in the (usually) three-number series should change whenever a non-backwards-compatible change is made. The .so version is generally NOT the same as the "human" version of the library.

03/13/07 20:16:00 changed by larsivi

I don't mind not versioning the libraries if we don't need it :)

04/04/07 21:05:34 changed by larsivi

  • status changed from assigned to closed.
  • resolution set to fixed.

This is up and running - problems should be noted via new tickets.