Ticket #40 (new task)

Opened 2 years ago

Last modified 1 year ago

Decide upon and implement a library installation standard

Reported by: allenb Assigned to: dirk
Priority: blocker Milestone: 2.0 Beta
Component: Build Version:
Keywords: Cc:
Completion:

Description

As it stands now we are simply building the OpenSG libraries and putting them in lib/debug or lib/opt. We need to go beyond this and think about how to handle versioning, symbolic links from lib/ and everything else involved in having a full install. This will probably take a bit of thought although we could start by using the pattern that Dirk has been using for RPMs and going from there.

Change History

(follow-up: ↓ 2 ) 09/13/06 21:14:21 changed by anonymous

Dev/PluginsPathes has my take on the installed structure. It might be good if the SCons build would automatically create a structure like this in the build.* hierarchy. That would simplify creating dists.

Versioning: do you mean version extensions on the libs or inside the code?

(in reply to: ↑ 1 ) 09/14/06 08:25:30 changed by allenb

Replying to anonymous:

Dev/PluginsPathes has my take on the installed structure. It might be good if the SCons build would automatically create a structure like this in the build.* hierarchy. That would simplify creating dists.

Agreed. I would consider it a bug if the scons build does not create the final hierarchy. To say this another way, creating a dist should not have to do anything more then call the scons build and give it a prefix.

Versioning: do you mean version extensions on the libs or inside the code?

On libs and headers. In other words how are we going to handle parallel installs and are they even going to be allowed?

(in reply to: ↑ description ; follow-up: ↓ 4 ) 09/14/06 17:37:19 changed by cneumann

Replying to allenb:

As it stands now we are simply building the OpenSG libraries and putting them in lib/debug or lib/opt. We need to go beyond this and think about how to handle versioning, symbolic links from lib/ and everything else involved in having a full install. This will probably take a bit of thought although we could start by using the pattern that Dirk has been using for RPMs and going from there.

I know this won't make things any easier, but I would think that having a fixed, i.e. not configurable, directory layout is going to drive package maintainers for distros nuts. Hence a good default is very nice and necessary, but I think the configurability one usually gets from auto-conf/auto-make (there are options for lib, bin, etc. prefixes) should at least be considered - although this particular aspect does not warrant the blocker status ;)

(in reply to: ↑ 3 ) 09/15/06 08:05:01 changed by dirk

Replying to cneumann:

I know this won't make things any easier, but I would think that having a fixed, i.e. not configurable, directory layout is going to drive package maintainers for distros nuts. Hence a good default is very nice and necessary, but I think the configurability one usually gets from auto-conf/auto-make (there are options for lib, bin, etc. prefixes) should at least be considered - although this particular aspect does not warrant the blocker status ;)

Given that this (hopefully) only touches on where the directories go, but not their internal structure, I would accept that to be changed in whatever distro builder is used.

It would probably not be a big deal to have scons install accept different directories for copying stuff anyway.