From Janez.Srakar at ijs.si Mon Feb 4 12:44:14 2008 From: Janez.Srakar at ijs.si (Janez Srakar) Date: Mon, 04 Feb 2008 12:44:14 +0100 Subject: [gled-bootstrap] test Message-ID: <1202125454.6014.12.camel@shiva.ijs.si> disregard, please. From jan.javorsek at guest.arnes.si Tue Nov 18 13:45:56 2008 From: jan.javorsek at guest.arnes.si (Jan Jona Javorsek) Date: Tue, 18 Nov 2008 13:45:56 +0100 Subject: [gled-bootstrap] greed install Message-ID: <4922B904.8070505@guest.arnes.si> Hi! As each year about this time, I am bugging you on the subject of an install target for gled. Install targets are nice for installing. And crucial for packaging. There are 2 kinds of packages: source (gentoo, bsd) where a simple install is enough, and binary, where the package maintainer has to split the software into different packages (i.e. exec / lib / devel / whatever). So, we have 3 issues: (1) How and where to install The default should be --prefix /usr/local (changed to /usr/ for packages, of course). According to standars, we have binaries /usr/bin/{gled,saturn,helperscripts} And non-dynamic-loader-loaded libraries in /usr/lib/gled/lib/ Other stuff, such as demos, cint files, textures (non-binaries): /usr/share/gled/{demos,...} Documentation and man files in proper places. Is this ok? Do I do it? (2) How gled should find its stuff (a) We can optionally compile-in the prefixes for packages and use them if env is not set. This is the ROOT way. (b) We can leave gled as it is and use wrapper scripts in bin. That would make gled /usr/bin/gled.bin and user would call /usr/bin/gled - a script that knows how to set env and calls /usr/bin/gled.bin. Ditto for all executables. (3) How to split up for binary packages. The obvious proposal as follows: * gled (virtual package) * gled-bin (binaries and GledCore) * [libsets] * gled-dev (header files, helper scrpts) * gled-doc * [libset]-dev (ditto) So one could make an application depend on gled (i.e, gree-prototype (gled => 1.3.0) and install gled-dev to get developer thingies and start a new project but only gled non-core libsets when required by depenencies. So much to annoy you... Best regards, -j. From matevz.tadel at cern.ch Thu Nov 20 13:45:15 2008 From: matevz.tadel at cern.ch (Matevz Tadel) Date: Thu, 20 Nov 2008 13:45:15 +0100 Subject: [gled-bootstrap] greed install In-Reply-To: <4922B904.8070505@guest.arnes.si> References: <4922B904.8070505@guest.arnes.si> Message-ID: <49255BDB.3000901@cern.ch> Howdy, [I've cc-ed Christian as he is the maintainer of the debian package root-system.] Jan Jona Javorsek wrote: > Hi! > > As each year about this time, I am bugging you on the subject of an > install target for gled. Good ... thanks for being resilient. > Install targets are nice for installing. > And crucial for packaging. And they force you to make proper configuration and build systems. The main issue with gled build is that the build of libsets [gled modules] depends on build-global configuratation, including the intermediate, build-spceific class catalogs, required for automatic code generators. > There are 2 kinds of packages: source (gentoo, bsd) where a simple > install is enough, and binary, where the package maintainer has to split > the software into different packages (i.e. exec / lib / devel / whatever). > > So, we have 3 issues: > > > (1) How and where to install > > The default should be --prefix /usr/local (changed to /usr/ for > packages, of course). > According to standars, we have binaries > /usr/bin/{gled,saturn,helperscripts} > > And non-dynamic-loader-loaded libraries in > /usr/lib/gled/lib/ > > Other stuff, such as demos, cint files, textures (non-binaries): > /usr/share/gled/{demos,...} > > Documentation and man files in proper places. > > Is this ok? Do I do it? This is fine, I agree. But, besides your next point, there is another issue: How can we support several concurrent versions of gled? I assume doing s/gled/gled-1.3.0/ on your proposal is fine. Then we have two options: 1. Use gled symlink (~/bin or system-wide) or use fully quantifed executable. 2. There is common script that runs the default one (/etc/gled.conf or the latest by default), takes an argument or uses an environment varable GLED_VERSION. This brings me to the reason why I cc-ed Christian - we will also require a different version of root for gled, and possibly a different one for each gled version. While we can bluntly infiltrate root inside /usr/lib/gled-x.y.z/root, this does not seem to be a long term solution. So ... the question is ... how does debian root-system handle this? From HEP point of view, I can imagine people having two versions of root: 1. the one required by the experiment framework, and 2. the latest one for running their analysis, making histograms, etc. > (2) How gled should find its stuff > > (a) We can optionally compile-in the prefixes for packages and use them > if env is not set. This is the ROOT way. > > (b) We can leave gled as it is and use wrapper scripts in bin. That > would make gled /usr/bin/gled.bin and user would call /usr/bin/gled - a > script that knows how to set env and calls /usr/bin/gled.bin. Ditto for > all executables. In a way I'd prefer wrapper scripts as they give you more flexibility. Especially if we also have to choose root version. > (3) How to split up for binary packages. The obvious proposal as follows: > > * gled (virtual package) > * gled-bin (binaries and GledCore) > * [libsets] > * gled-dev (header files, helper scrpts) > * gled-doc > * [libset]-dev (ditto) > > So one could make an application depend on gled (i.e, gree-prototype > (gled => 1.3.0) > and install gled-dev to get developer thingies and start a new project > but only gled non-core libsets when required by depenencies. This can be done realtively easily for the binary packages. For devel stuff I'll have to fix gled configuration / build first. Fixing this will be one of my first priorities after we're done with 1.3.0. > So much to annoy you... No no ... it was a pleasure :) I know we should have done that a long time ago. Best, Matevz > Best regards, > -j. From cholm at nbi.dk Thu Nov 20 23:49:34 2008 From: cholm at nbi.dk (Christian Holm Christensen) Date: Thu, 20 Nov 2008 23:49:34 +0100 Subject: [gled-bootstrap] greed install In-Reply-To: <49255BDB.3000901@cern.ch> References: <4922B904.8070505@guest.arnes.si> <49255BDB.3000901@cern.ch> Message-ID: <1227221374.12821.59.camel@cholm.priv.nbi.dk> Hi Matevz and Jan, On Thu, 2008-11-20 at 13:45 +0100, Matevz Tadel wrote: > Howdy, Caveat: I haven't the fainest idea what gled is all about. Please keep that in mind. > [I've cc-ed Christian as he is the maintainer of the debian package root-system.] Yup, that's me :-) > Jan Jona Javorsek wrote: > > Hi! > > > > As each year about this time, I am bugging you on the subject of an > > install target for gled. > > Good ... thanks for being resilient. > > > Install targets are nice for installing. > > And crucial for packaging. > > And they force you to make proper configuration and build systems. What build system are you guys using? I hope it's a time-tried, resilient, and "standard" one like Autotools. > The main issue with gled build is that the build of libsets [gled modules] > depends on build-global configuratation, including the intermediate, > build-spceific class catalogs, required for automatic code generators. OK, you lost me. > > There are 2 kinds of packages: source (gentoo, bsd) where a simple > > install is enough, and binary, where the package maintainer has to split > > the software into different packages (i.e. exec / lib / devel / whatever). For Debian you should have packages like * libgled - Run-time libraries only (e.g., libgled.so., libgled.so..) * libgled-dev - Development package including headers, link libraries, and static archives (/usr/include/gled/*.h, libgled.so, libgled.a). If your project has the need for it, then other packages can be made, like * gled-bin - applications of sorts (/usr/bin/). * gled-common - architecture independent data files needed by the package (/usr/share/gled/) * gled-doc - Documentation of the project (/usr/share/doc/gled, but _not_ including man(1) pages which must go with the corresponding binary). If you project has optional parts either in the form of plug-ins or additional run-time libraries, guis, or so, you can have packages like * gled-plugin- - runtime loadable plug-in * libgled- - runtime extension library . Note, if provides additional header files that the users can include, then these _must_ be put in the separate package libgled--dev. * gled-gui - e.g., GUIs or the like. > > So, we have 3 issues: > > > > > > (1) How and where to install > > > > The default should be --prefix /usr/local (changed to /usr/ for > > packages, of course). If you use a proper build-system like Autotools, then this is automatic. > > According to standars, we have binaries > > /usr/bin/{gled,saturn,helperscripts} > > > > And non-dynamic-loader-loaded libraries in > > /usr/lib/gled/lib/ Erhm, /usr/lib/gled is the right thing. There's no need for the additional "/lib" sub-directory. If you're thinking about plug-ins here, perhaps you should rather do /usr/lib/gled/plugins. > > Other stuff, such as demos, cint files, textures (non-binaries): > > /usr/share/gled/{demos,...} Demos should go in /usr/share/doc/gled/demos. You should not distribute CINT generated dictionaries. There's no need, and the content is highly volatile. Data files, if platform independent, _must_ go in /usr/share/gled (or sub-directories). > > Documentation and man files in proper places. > > > > Is this ok? Do I do it? Why are you worrying about all these things? If you choose to use Autotools, all this is given for you automatically. > This is fine, I agree. But, besides your next point, there is another issue: How > can we support several concurrent versions of gled? I think it's important that you ask yourself why do you need to be able to install several version of the same software on a single machine? That said, you _must_ be able to install multiple version of the run-time libraries on the target machine. Run-time libraries have a so-called so-version (shared object version number) in the file name, and the dynamic loader will look for this version when resolving dependencies at run-time. Do an ldd on your favourite application to see what I mean. The way to build this in to a shared library is by doing (GCC, Linux): g++ -shared -Wl,-soname,libgled.so.3 -o libgled.so.3.0 object1.o ... ln -s libgled.so.3.0 libgled.so.3 The so-name is set explicitly here, and we make a link so that the dynamic loader can find the library. Now, since the so-version - or interface version - is in the file name, you can easily have multiple version of the same library on the same host: /usr/lib/libgled.so.3.0 /usr/lib/libgled.so.3 -> libgled.so.3.0 /usr/lib/libgled.so.4.5 /usr/lib/libgled.so.4 -> libgled.so.4.5 This is the reason why for the part of the package names above, and why Debian enforces this. Note, Red Hat does _not_ enforce this (sic - which is also why maintaining a Red Hat machine is a pain the butt) but the don't block it either. For development (and _only_ development), you need the sym-link /usr/lib/libgled.so -> libgled.so. Obviously, there can only be one such link on a given host. However, this is not a problem. When you do development, you do it against a single specific version (by default, the latest). For applications linked against the gled libraries, you need only a single version (probably the latest and greatest). If you _do_ for some god-forsaken-reason need several version, then you should look into the alternatives system on Debian and Red Hat (not in SL yet - sic). > I assume doing s/gled/gled-1.3.0/ on your proposal is fine. Then we have two > options: If you have plug-ins, and the depend strongly on the interface version of you libraries, or worse, on the project version, then you should have a separate plug-in directory for each version e.g., /usr/lib/gled//plugins > 1. Use gled symlink (~/bin or system-wide) or use fully quantifed executable. Argh, do not assume _anything_ about the users home directory or environment - that's the worst thing you can do, and Debian would never accept it. Fully qualified executable (e.g., gled-4.5) is ok, by you should seriously consider some why of specifying a default version (again, look into the alternatives system). > 2. There is common script that runs the default one (/etc/gled.conf or the > latest by default), takes an argument or uses an environment varable GLED_VERSION. Argh. No environment variables - this is important for making distribution-quality packages. While a common script might at first sound appealing, it has it own problems. How do you "upgrade" the common script? The alternatives system takes care of all that for you. For systems without an alternatvies system, you can think of have a package like "gled-bin-defaults-" which would move symlinks or the like (a poor-mans alternative system). > This brings me to the reason why I cc-ed Christian - we will also require a > different version of root for gled, and possibly a different one for each gled > version. The ROOT packages fully support different run-time libraries. They do not support different executable version, since there's no need. > While we can bluntly infiltrate root inside /usr/lib/gled-x.y.z/root, > this does not seem to be a long term solution. Udhr, that's ugly. You should really do your outmost to not bundle third-party software in your project. Debian has a very hard time with that (for good reasons - avoid bloat - after all, it's not Windoze :-) > So ... the question is ... how does debian root-system handle this? From HEP > point of view, I can imagine people having two versions of root: 1. the one > required by the experiment framework, and 2. the latest one for running their > analysis, making histograms, etc. Erhm, no. Most users only ever install a single package. This idea that you need more than one version of ROOT is plain silly. What _can_ happen, and this is supported by the root-system packages, is that some experiment builds some libraries (plug-ins or extensions), and executables linked against a specific version of ROOT. The fact that the so-version is in the package name allows us to upgrade the ROOT executables (pulling in new run-time libraries without deleting the old ones) and still be able to run the experiment-specific executable linked against the older ROOT shared libraries. Plug-ins are dealt with the same way. > > (2) How gled should find its stuff > > > > (a) We can optionally compile-in the prefixes for packages and use them > > if env is not set. This is the ROOT way. Erhm, no. You can build ROOT in two ways: Either you _must_ set ROOTSYS, or you have preset paths. You cannot have both (even though I've pushed for this for many years now). The way to do this is simple. You make a singleton class that serves paths. The class can inspect the environment for specific settings if needed. For example #define PLUGIN_PATH "/usr/lib/gled/plugins" class PathManager { public: static PathManager& Instance() { if (!fgInstance) fgInstance = new PathManager; return fgInstance; } TString GetFromEnvOrPreset(const char* env, const char* preset) { TString ret; if (gSystem->Getenv(env)) ret = gSystem->Getenv(env); else ret = preset; return ret; } const char* GetPluginPath() const { if (fgPluginPath.IsEmpty()) fgPluginPath = GetFromEnvOrPreset("GLED_PLUGIN_PATH", PLUGIN_PATH); return fgPluginPath.Data(); } ... }; > > (b) We can leave gled as it is and use wrapper scripts in bin. Not so nice. > That > > would make gled /usr/bin/gled.bin and user would call /usr/bin/gled - a > > script that knows how to set env and calls /usr/bin/gled.bin. Ditto for > > all executables. One of reasons why that's not all that nice, is that it doesn't scale. > In a way I'd prefer wrapper scripts as they give you more flexibility. > Especially if we also have to choose root version. But you cannot freely choose a ROOT version. Your code is complied and linked against a specific ROOT version, and you should never try to link, load, or run with a different version. The so-version in the so-name protects you against this, since the dynamic loader cannot resolve against a library of a different version than the one used at run-time. > > (3) How to split up for binary packages. The obvious proposal as follows: > > > > * gled (virtual package) > > * gled-bin (binaries and GledCore) > > * [libsets] > > * gled-dev (header files, helper scrpts) > > * gled-doc > > * [libset]-dev (ditto) See above. > > So one could make an application depend on gled (i.e, gree-prototype > > (gled => 1.3.0) > > and install gled-dev to get developer thingies and start a new project > > but only gled non-core libsets when required by depenencies. Your dependencies should always be the minimal set of packages. Debian has two more levels of dependencies: Recommends and Suggests. The first says: This package will work best if you install the recommended one. The second says: This package can make good use of the suggested package but you may not really need it, so it's up to you if you want it or not. Red Hat does not have this - either it's a dependency or it's not. I suggest you read through the FHS and the Debian policies. Note, that Debian is by far the most strict of all the distributions (which, btw, is what makes it so more stable than any other distribution). Hence, if you can make it into Debian, your doing pretty good. My 2 ?? Yours, -- ___ | Christian Holm Christensen |_| | ------------------------------------------------------------- | | Address: Sankt Hansgade 23, 1. th. Phone: (+45) 35 35 96 91 _| DK-2200 Copenhagen N Cell: (+45) 24 61 85 91 _| Denmark Office: (+45) 353 25 447 ____| Email: cholm at nbi.dk Web: www.nbi.dk/~cholm | | From jan.javorsek at guest.arnes.si Fri Nov 21 11:45:10 2008 From: jan.javorsek at guest.arnes.si (Jan Jona Javorsek) Date: Fri, 21 Nov 2008 11:45:10 +0100 Subject: [gled-bootstrap] greed install In-Reply-To: <1227221374.12821.59.camel@cholm.priv.nbi.dk> References: <4922B904.8070505@guest.arnes.si> <49255BDB.3000901@cern.ch> <1227221374.12821.59.camel@cholm.priv.nbi.dk> Message-ID: <49269136.1030300@guest.arnes.si> (By mistake sent only to Christian, resending for list and matevz). Christian Holm Christensen wrote: >> [I've cc-ed Christian as he is the maintainer of the debian package root-system.] >> > > Yup, that's me :-) > > Hello there, glad you joined in! I must admit your explanation is probably the densest and most information rich recapitulation of Debian packaging policy I have seen to date, so welcome indeed. On the other hand, my debian packaging so far has been amateurish at best, and my involvement in gled hampered by my poorish C++, so please forgive any silliness from my part. > > What build system are you guys using? I hope it's a time-tried, > resilient, and "standard" one like Autotools. > > Well, yes and no. Matevz switched to Autotools for most things, but Gled itself still uses its own slightly original system based on a perl configure and make. While I think he is considering going for Autotools there, Gled has some curious and specific needs (inter-libset dependencies, custom dictionaries (not CINT), code generation) so a switch is not exactly trivial at this point. And, of course, it is easier to monkey around when ROOT abstracts much of your OS APIs. But I think I share with you the inner joy of wrestling with original configuration and building systems and exciting things (such as scons, so far it gave me shudders and many errors, or, god forbid, multiple solutions). (Btw, how is cmake in your opinion? We are also looking into BSD/Mac/MSWin ports, so any opinions are more than welcome. Perhaps you remember some ROOT patches for BSD lately from a collegue of mine, that was somehow related.) >> The main issue with gled build is that the build of libsets [gled modules] >> depends on build-global configuratation, including the intermediate, >> build-spceific class catalogs, required for automatic code generators. >> > > OK, you lost me. > > >From my point of view, the missing information is that gled can be two things: it can be a library and executable that can run cint scripts and interactive sessions or it can be used as a development framework and toolkit. It is built as an executable and a number or dlopen-loaded library sets called lbsets (that effectively mostly behave as plugins). However, it is possible to configure a libset in such a way the build system builds you the libraries but also executables (tools or a main program). In fact, gled's main executable resides in the GledCore libset. This is practical, but complicates relationships between the build system and packaging a wee little bit. On the other hand, when used as a development framework and toolkit, you need access to the helper scripts, build environment, libset libraries etc., and everything has to be set up in such a way that correct versions of gled and root parts are used. In this case, you can imagine the user building a new executable that will link (actually, dlopen) properly versioned libraries, but still using gled executable as a monitoring tool for object inspection etc. > For Debian you should have packages like > > * libgled - Run-time libraries only (e.g., > libgled.so., libgled.so..) > * libgled-dev - Development package including headers, link > libraries, and static archives (/usr/include/gled/*.h, > libgled.so, libgled.a). > > If your project has the need for it, then other packages can be made, > like > > * gled-bin - applications of sorts (/usr/bin/). > * gled-common - architecture independent data files needed by the > package (/usr/share/gled/) > * gled-doc - Documentation of the project (/usr/share/doc/gled, > but _not_ including man(1) pages which must go with the > corresponding binary). > > If you project has optional parts either in the form of plug-ins or > additional run-time libraries, guis, or so, you can have packages like > > * gled-plugin- - runtime loadable plug-in > * libgled- - runtime extension library . Note, > if provides additional header files that the users can > include, then these _must_ be put in the separate package > libgled--dev. > * gled-gui - e.g., GUIs or the like. > > Now _this_ is a much more complete and to the point explanation than what I have been able to came up after many years of living with debian! > Erhm, /usr/lib/gled is the right thing. There's no need for the > additional "/lib" sub-directory. If you're thinking about plug-ins > here, perhaps you should rather do /usr/lib/gled/plugins. > > Yes, of course, error on my part. We have some versioned binaries never run by the user, and since those go to /usr/libexec, we can have /usr/lib/gled-version/libset-name/*.so* >>> Other stuff, such as demos, cint files, textures (non-binaries): >>> /usr/share/gled/{demos,...} >>> > > Demos should go in /usr/share/doc/gled/demos. > > You should not distribute CINT generated dictionaries. There's no need, > and the content is highly volatile. > If I get this correcty, you are suggesting the CINT generated dictionaries should be recreated by the post-install script? If not, I lost you there due to my lack of exposure to ROOT other than via Gled. > Data files, if platform independent, _must_ go in /usr/share/gled (or > sub-directories). > Including CINT scripts, as most demos are CINT scripts. Of course, thank you. >> This is fine, I agree. But, besides your next point, there is another issue: How >> can we support several concurrent versions of gled? >> > > I think it's important that you ask yourself why do you need to be able > to install several version of the same software on a single machine? > > I think the main issue would be when one would want to use Gled as a developing environment, and also use the newest version, and using a released stable Gled with some existing application. Since currently Gled uses a copy of the ROOT environment thingh (GLEDSYS and also ROOTSYS to find its ROOT), it seems silly to loose that ability, and at the same time since we will have concurrent versions of the libraries, it would not hurt to have compatible executables. >> 1. Use gled symlink (~/bin or system-wide) or use fully quantifed executable. >> > > Argh, do not assume _anything_ about the users home directory or > environment - that's the worst thing you can do, and Debian would never > accept it. Fully qualified executable (e.g., gled-4.5) is ok, by you > should seriously consider some why of specifying a default version > (again, look into the alternatives system). > > yess, alternatives is definitely the right solution for that. i am shocked, however, that it is not in slc yet. it can't be that hard now, can it? if even the ubuntu people can be made to understand that. On the other hand, what i would like to achieve is that a user on a multiuser machine is able to select a version of gled and create a new libset with it. the new libset build directory should then be able to know on which version it is supposed to build itself and be able to compile and package itself. It is at this point I am looking into ENV, script and similar solutions. Of course, we have to provide a way to change that, so that the user can upgrade gled, change the information on the libset, try to compile and fix for any incompatibilities. Yess, it will be a joyful ride. > The ROOT packages fully support different run-time libraries. They do > not support different executable version, since there's no need. > > Good point. And since GLED does not need the executable, that does not present any problems. But how is CINT handled in this respect? We would need the correct rootcint to build dictionaries in development version and for pakcage installation if I understand correctly and you think this should be done in postinstall. >> While we can bluntly infiltrate root inside /usr/lib/gled-x.y.z/root, >> this does not seem to be a long term solution. >> > > Udhr, that's ugly. > Yes, surely everyone wants some 7 ROOT installations hangling around their laptopos. > What _can_ happen, and this is supported by the root-system packages, is > that some experiment builds some libraries (plug-ins or extensions), and > executables linked against a specific version of ROOT. The fact that > the so-version is in the package name allows us to upgrade the ROOT > executables (pulling in new run-time libraries without deleting the old > ones) and still be able to run the experiment-specific executable linked > against the older ROOT shared libraries. Plug-ins are dealt with the > same way. > Yes, I think that pretty much sums up our situation, where we imagine people to sit around with HEP stuff linked with a not-so-fresh ROOT and Gled with the latest-and-greates ROOT release (since that is usually needed). > Erhm, no. You can build ROOT in two ways: Either you _must_ set > ROOTSYS, or you have preset paths. You cannot have both (even though > I've pushed for this for many years now). > > Ech, sorry, I thought it was done that way, but now I remember being surprized at it when I first found out about it. I agree with you completely - why remove some flexibility when you don't have to. But I digress, and it is easy to be a critic. > The way to do this is simple. You make a singleton class that serves > paths. The class can inspect the environment for specific settings if > needed. For example > > #define PLUGIN_PATH "/usr/lib/gled/plugins" > > class PathManager { > public: > static PathManager& Instance() { > if (!fgInstance) fgInstance = new PathManager; > return fgInstance; > } > TString GetFromEnvOrPreset(const char* env, const char* preset) > { > TString ret; > if (gSystem->Getenv(env)) > ret = gSystem->Getenv(env); > else > ret = preset; > return ret; > } > const char* GetPluginPath() const > { > if (fgPluginPath.IsEmpty()) > fgPluginPath = GetFromEnvOrPreset("GLED_PLUGIN_PATH", PLUGIN_PATH); > return fgPluginPath.Data(); > } > ... > }; > > Seems nice. Matevz? >>> (b) We can leave gled as it is and use wrapper scripts in bin. >>> > > Not so nice. > > Agreed. This was meant more as a 'we can do this now and worry about it for the next release' proposal. > >> In a way I'd prefer wrapper scripts as they give you more flexibility. >> Especially if we also have to choose root version. >> > > But you cannot freely choose a ROOT version. Your code is complied and > linked against a specific ROOT version, and you should never try to > link, load, or run with a different version. The so-version in the > so-name protects you against this, since the dynamic loader cannot > resolve against a library of a different version than the one used at > run-time. > > Of course. I was thinking of the situation where Gled is used as a development framework and we have to specify the correct ROOT headers for the used libraries. Luckily, if memory holds, Debian allows only one version of a development package installed at the time, so we can try not to complicate this further. >>> So one could make an application depend on gled (i.e, gree-prototype >>> (gled => 1.3.0) >>> and install gled-dev to get developer thingies and start a new project >>> but only gled non-core libsets when required by depenencies. >>> > > Your dependencies should always be the minimal set of packages. Absolutely. I was trying to point that out to Matevz who has been trying to steer as far from packaging as possible, but your explanation seems a lot more concise, thanx. > Note, that > Debian is by far the most strict of all the distributions (which, btw, > is what makes it so more stable than any other distribution). That is why I am starting packaging with Debian. Once this is done, the rest should be easy(er). > Hence, if > you can make it into Debian, your doing pretty good. > In fact, we are only aiming to produce the packages for installation from our own repository at this time. It is a very bad time at the Debian side (lenny freeze and all) and Gled is in a bit of a overhaul for the release, so I will only try to get it in Debian with the next release. However, if we manage to produce something palatable, I will need a mentor to become a Debian maintainer and get it in since so far all my packages have been for private or local use only. In this spirit, your comments are more than welcome and I hope to be able to make thinks as compliant as possible under the circumstances. Thanks for the help and I hope for more comments, -jan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.gled.org/pipermail/gled-bootstrap/attachments/20081121/9a4a17f5/attachment.html From matevz.tadel at cern.ch Sat Nov 22 21:47:01 2008 From: matevz.tadel at cern.ch (Matevz Tadel) Date: Sat, 22 Nov 2008 21:47:01 +0100 Subject: [gled-bootstrap] greed install In-Reply-To: <1227299728.14247.91.camel@cholm.priv.nbi.dk> References: <4922B904.8070505@guest.arnes.si> <49255BDB.3000901@cern.ch> <1227221374.12821.59.camel@cholm.priv.nbi.dk> <492690EB.8070407@guest.arnes.si> <1227299728.14247.91.camel@cholm.priv.nbi.dk> Message-ID: <49286FC5.7000207@cern.ch> Hi Christian, Jona, First, many thanks to both of you for going into such depth - I think it is mostly clear to me now what needs to done on the grand scale. As the situation is somewhat complex (screwed up), I'll take the evolutionary approach, starting with the runtime configuration cleanup and build modularization. Then i'll get back to you with a concrete proposal for packaging. But first, some comments and questions. [I've snipped the parts that seemed to be agreed upon.] Christian Holm Christensen wrote: >>> What build system are you guys using? I hope it's a time-tried, >>> resilient, and "standard" one like Autotools. >>> >> Well, yes and no. Matevz switched to Autotools for most things, but >> Gled itself still uses its own slightly original system based on a >> perl configure and make. While I think he is considering going for >> Autotools there, Gled has some curious and specific needs >> (inter-libset dependencies, custom dictionaries (not CINT), code >> generation) so a switch is not exactly trivial at this point. > > Autotools is actually very good at dealing with "inter-libset > dependencies". Custom commands for generated code is also possible, as > in normal Makefiles, and supported well. Historically, when I started working on gled in '98, the autotools were still not the standard they are today. Also, root and fltk, the main dependencies of gled-core, were not part of any distribution ... the same was true for other externals when I started to use them (DevIL, gts, openal). gled was, and still is, a opus nigrum project, hardcore GNU/linux, even thinking about windows seemed a blasphemy. We tried to go public with it in 2003 but nobody seemed to care ... so there was no strong incentive to generalize the build system. Now that we'll soon try to go public again, we would like to make it right - have a proper build system and hopefully soon also mac and windows ports. autoconf is used now for configuration of the top-level build system - the one that builds all externals (which mostly use autotools internally) and gled itself. How do autotools work on windows? I can imagine one needs cygwin ... but can one use M$ compiler and linker? >>>> The main issue with gled build is that the build of libsets [gled modules] >>>> depends on build-global configuratation, including the intermediate, >>>> build-spceific class catalogs, required for automatic code generators. >>>> >>> OK, you lost me. >>> >>> >> From my point of view, the missing information is that gled can be >> two things: it can be a library and executable that can run cint >> scripts and interactive sessions or it can be used as a development >> framework and toolkit. > > OK, fine. So for developers you have libraries and headers. For users, > you have programs. Both need runtime libraries. > >> It is built as an executable and a number or dlopen-loaded library >> sets called lbsets (that effectively mostly behave as plugins). > > Please note, that you should _not_ give loaded modules names like > lib.so. Instead, call them .so. In that way, it's obvious > that the developer should not try to link against these. Libsets themselves are linked against other libsets and other required libraries. This is different than root approach where libraries are not linked against other root libraries. What's your opinion on that? >> However, it is possible to configure a libset in such a way the build >> system builds you the libraries but also executables (tools or a main >> program). In fact, gled's main executable resides in >> the GledCore libset. > > Fine, so you have a Java-like main class > > public class HelloWorld > { > public HelloWorld() { } > public void run() > { > System.out.println("Hello, World"); > } > public static void main(String[] args) > { > HelloWorld h = new HelloWorld(); > h.run(); > } > } > > It should still go in a run-time library since the developer may > actually want to extend it. > > public class GoodbyeWorld extends HelloWorld > { > public GoodbyeWorld() {} > public void run() > { > super.run(); > System.out.println("Goodbye, World"); > } > public static void main(String[] args) > { > HelloWorld h = new GoodbyeWorld(); > h.run(); > } > } > > The fact that the program it self is darn simple > > #include > > int main(int argc, char** argv) > { > gled::core::Main m(argc, argv); > return m.Run(); > } > > doesn't really change things - it's still a program. This is already done like that. The main base-class is called Gled, and its sub-class GledGUI can be used to invoke the version with GUI. The actual executables still contain some more code ... but it would be trivial to put it in the classes themselves. >> This is practical, but complicates relationships between the build >> system and packaging a wee little bit. > > How? > >> On the other hand, when used as a development framework and toolkit, >> you need access to the helper scripts, > > Helper scripts, like gled-config, etc. can go in the libgled-dev > package. So ... these should all be part of the GledCore? Now we have a separate gled-build package that contains build helper-scripts and serves as the environment for simultaneous work on several libsets. This means, if I change something in GledCore, all dependant libsets will get properly recompiled. If we completely separate the build environment of each libset, the developer would have to know what to rebuild ... in proper order. >> build environment, > > You should refrain from imposing a built environment on the developer. > It won't work. Instead, provide stuff to be used for the most common > build-systems (pkgconfig, m4 macros for Autotools, CMake stuff, and so > on - and of course the obligatory gled-config :-). As I said above ... I think I could make this work for a single libset. >> libset libraries etc., > > If your "libsets" are truly plug-ins (i.e., conforming to an interface), > then you do not need access to the libsets as development libraries. > All you need, is the interface declaration. Well ... they are really libraries ... but they also contain bootstrap functions that register the library contents into gled catalogs. They also contain the list of libsets they depend on ... so their bootstrap functions can be called first (as libsets are linked against other libsets). >> and everything has to be set up in such a way that correct versions of >> gled and root parts are used. > > There's no problem as long as you use so-version. If you try to link > against a both gled libraries linked against ROOT version X, at the same > time as you are linking against ROOT version Y, you will get errors. > That said, you should use libtool to make the gled libraries depend on > the ROOT libraries used at run-time. Wicked, yess. First I got parse-error, then went and read the libtool docs. So you do everything with libtool - compilation and linking. >>>>> Other stuff, such as demos, cint files, textures (non-binaries): >>>>> /usr/share/gled/{demos,...} >>>>> >>> Demos should go in /usr/share/doc/gled/demos. >>> >>> You should not distribute CINT generated dictionaries. There's no need, >>> and the content is highly volatile. >>> >> If I get this correcty, you are suggesting the CINT generated >> dictionaries should be recreated by the post-install script? > > No. The dictionaries are compiled into your libraries/plug-ins/... and > there's no need for the end-user/developer to ever see these files. > Simply do not distribute those files generated by rootcint/cint. The situation is slightly different in gled as project7 (gled's parser-codegen) requires dumps from base libsets. Now they are all contained in the top build environment but I'm pretty sure I could make proper perl modules of them, put them in /usr/share/gled/perllib and distribute them with libset-devel. >> On the other hand, what i would like to achieve is that a user on a >> multiuser machine is able to select a version of gled and create a new >> libset with it. > > Why? > > The system should provide _one_ and only one version of your package for > development. If the user for some god-forsaken-reason needs an older > version, she would have to put in the effort to install it herself. > There's no reason to support more than one version of a given software > package (how many versions of X do you have on your machine? How many > versions of OpenOffice.org? Gimp? Emacs? Java?). > > gled is certainly not the only HEP application that thinks having > multiple version of the same software on a single machine is a brillant > idea. It is down right ridiculous. If your applications isn't > stable/feature-rich enough that all users can use the latest release, > then it does not belong in the system but in the sandboxes of the > developers and interested users. Well ... if we're talking about root here ... I have 6 different versions on my desktop :) four trunks, one branch off 5.18 (for cms) and one tagged version (for alice). Otherwise I agree. >> the new libset build directory should then be able to know on which >> version it is supposed to build itself and be able to compile and >> package itself. > > Why are you talking about libsets build themselves? Aren't you talking > about making binary distributions? Yesss ... that's Jona's dream ... to have an easy way of starting your own libset with the installed version of gled. But I see no issue here (as Christian already replied about rootcint version) ... you use the latest version ... the one you also have the devel stuff for. >> Good point. And since GLED does not need the executable, that does not >> present any problems. But how is CINT handled in this respect? We >> would need the correct rootcint to build dictionaries in development >> version and for pakcage installation if I understand correctly and you >> think this should be done in postinstall. > > No. > > rootcint is in the development package libroot-core-dev. As such, there > can only be one installed version. Again, this make sense, as you are > most likely doing development against some specific release (most often > the latest). If you for some reason need to develop against an older > release, you would need to pin that package > > apt-get install libroot-core-dev=5.20-1 > >>>> While we can bluntly infiltrate root inside /usr/lib/gled-x.y.z/root, >>>> this does not seem to be a long term solution. >>>> >>> Udhr, that's ugly. >>> >> Yes, surely everyone wants some 7 ROOT installations hangling >> around their laptopos. > > No, no-one wants that. You only want (possibly) enough run-time > libraries of different version to run the applications you have > installed. The rest is uni-version only. See also the following > paragraph. Good, point taken. >>> What _can_ happen, and this is supported by the root-system packages, is >>> that some experiment builds some libraries (plug-ins or extensions), and >>> executables linked against a specific version of ROOT. The fact that >>> the so-version is in the package name allows us to upgrade the ROOT >>> executables (pulling in new run-time libraries without deleting the old >>> ones) and still be able to run the experiment-specific executable linked >>> against the older ROOT shared libraries. Plug-ins are dealt with the >>> same way. >> Yes, I think that pretty much sums up our situation, where we imagine >> people to sit around with HEP stuff linked with a not-so-fresh ROOT >> and Gled with the latest-and-greates ROOT release (since that is >> usually needed). >> >>> Erhm, no. You can build ROOT in two ways: Either you _must_ set >>> ROOTSYS, or you have preset paths. You cannot have both (even though >>> I've pushed for this for many years now). >>> >>> >> Ech, sorry, I thought it was done that way, but now I remember being >> surprized at it when I first found out about it. I agree with you >> completely - why remove some flexibility when you don't have to. But I >> digress, and it is easy to be a critic. > > I've submitted many concrete proposals - all have gone ignored :-( Maybe we can try again after 5.22 is out ... this shouldn't be a major change, I guess. >>> The way to do this is simple. You make a singleton class that serves >>> paths. The class can inspect the environment for specific settings if >>> needed. For example >>> >>> #define PLUGIN_PATH "/usr/lib/gled/plugins" >>> >>> class PathManager { >>> public: >>> static PathManager& Instance() { >>> if (!fgInstance) fgInstance = new PathManager; >>> return fgInstance; >>> } >>> TString GetFromEnvOrPreset(const char* env, const char* preset) >>> { >>> TString ret; >>> if (gSystem->Getenv(env)) >>> ret = gSystem->Getenv(env); >>> else >>> ret = preset; >>> return ret; >>> } >>> const char* GetPluginPath() const >>> { >>> if (fgPluginPath.IsEmpty()) >>> fgPluginPath = GetFromEnvOrPreset("GLED_PLUGIN_PATH", PLUGIN_PATH); >>> return fgPluginPath.Data(); >>> } >>> ... >>> }; >>> >>> >> Seems nice. Matevz? Aye, will make it so! But wait ... where does one put this? If it is in GledCore, it is already too late. If it is in the executable, then the whole plugin loader should be there as well, to load GledCore. Thanks again! Best, Matevz From cholm at nbi.dk Mon Nov 24 14:23:11 2008 From: cholm at nbi.dk (Christian Holm Christensen) Date: Mon, 24 Nov 2008 14:23:11 +0100 Subject: [gled-bootstrap] greed install In-Reply-To: <49286FC5.7000207@cern.ch> References: <4922B904.8070505@guest.arnes.si> <49255BDB.3000901@cern.ch> <1227221374.12821.59.camel@cholm.priv.nbi.dk> <492690EB.8070407@guest.arnes.si> <1227299728.14247.91.camel@cholm.priv.nbi.dk> <49286FC5.7000207@cern.ch> Message-ID: <1227532991.5373.64.camel@cholm.priv.nbi.dk> Hi Matevz, On Sat, 2008-11-22 at 21:47 +0100, Matevz Tadel wrote: > Hi Christian, Jona, > > First, many thanks to both of you for going into such depth - I think it is > mostly clear to me now what needs to done on the grand scale. > > As the situation is somewhat complex (screwed up), I'll take the evolutionary > approach, starting with the runtime configuration cleanup and build > modularization. Then i'll get back to you with a concrete proposal for packaging. > > But first, some comments and questions. > > [I've snipped the parts that seemed to be agreed upon.] > > > > Christian Holm Christensen wrote: > >>> What build system are you guys using? I hope it's a time-tried, > >>> resilient, and "standard" one like Autotools. > >>> > >> Well, yes and no. Matevz switched to Autotools for most things, but > >> Gled itself still uses its own slightly original system based on a > >> perl configure and make. While I think he is considering going for > >> Autotools there, Gled has some curious and specific needs > >> (inter-libset dependencies, custom dictionaries (not CINT), code > >> generation) so a switch is not exactly trivial at this point. > > > > Autotools is actually very good at dealing with "inter-libset > > dependencies". Custom commands for generated code is also possible, as > > in normal Makefiles, and supported well. ... > gled was, and still is, a opus nigrum project, hardcore GNU/linux, even thinking > about windows seemed a blasphemy. We tried to go public with it in 2003 but > nobody seemed to care ... so there was no strong incentive to generalize the > build system. > > Now that we'll soon try to go public again, we would like to make it right - > have a proper build system and hopefully soon also mac and windows ports. > > autoconf is used now for configuration of the top-level build system - the one > that builds all externals (which mostly use autotools internally) and gled itself. Do you mean to say, that you have "bundled" third-party software? That's a very bad idea indeed. First of all, it may cause bloat, secondly, it will make it harder for you to track developments in third-party tools, and thridly, most distributions frown upon "bundling". > How do autotools work on windows? I can imagine one needs cygwin ... but can one > use M$ compiler and linker? Autotools works on any Posix/*nix/*BSD (including MacOSX which has a very tricky dynamic load library build-requirement). Since Cygwin is a Posix layer, it means that Autotools works out of the box. For Windoze native builds (using M$ Virtual C++, etc), Autotools is almost there (last I checked at least - which was 1 year ago or so). They require a fix tricks here and there. > > > >>>> The main issue with gled build is that the build of libsets [gled modules] > >>>> depends on build-global configuratation, including the intermediate, > >>>> build-spceific class catalogs, required for automatic code generators. > >>>> > >>> OK, you lost me. > >>> > >>> > >> From my point of view, the missing information is that gled can be > >> two things: it can be a library and executable that can run cint > >> scripts and interactive sessions or it can be used as a development > >> framework and toolkit. > > > > OK, fine. So for developers you have libraries and headers. For users, > > you have programs. Both need runtime libraries. > > > >> It is built as an executable and a number or dlopen-loaded library > >> sets called lbsets (that effectively mostly behave as plugins). > > > > Please note, that you should _not_ give loaded modules names like > > lib.so. Instead, call them .so. In that way, it's obvious > > that the developer should not try to link against these. > > Libsets themselves are linked against other libsets and other required > libraries. This is different than root approach where libraries are not linked > against other root libraries. What's your opinion on that? First, lets make the distinction between libraries and plug-ins clear. (Callable) Libraries are part of the run-time system, and as such, it's usually up to the system dynamic loader to load the needed libraries as needed. This implies that all the symbols of the library is known at link-time. Libraries are also "extension" in that they provide new functionality. Developers should be able to take advantage of these extension by developing and linking against these libraries. This implies that the package must distribute the relevant development libraries (lib.so) and headers in standard locations (/usr/lib/, /usr/include/). Examples of this in the ROOT world are libRooFit, libGeom, and libPhysics. Plug-ins are by contrast part of the run-time package. That is, it is up to the application to load these as needed. In an open architecture, the plug-ins all conform to a given (set of) interface(s). That is, when the package loads the plug-in it knows how to deal with the code in the plug-in since it conforms to a given interface. Since the plug-ins implement a particular interface, it means that developers need not be exposed to the particularities of the plug-in. That is, the plug-in must not distribute headers or development libraries. This in turn implies that the plug-ins can reside anywhere convenient to the package (e.g., /usr/lib//plugins). Examples of plug-ins in the ROOT world are libMinuit, libMinuit2, libMySQL, libRPSQL, and libOracle. It is actually easier to illustrate this by using Java. In Java, a class can "extend" another class, or "implement" an interface. public class Foo { public void doSomething() { ... } } public class Bar { public void doSomething() { ... } public void doSomethingElse() { ... } } public interface Doer { public void doIt(); } public class MyDoer implements Doer { public void doIt() { ... } } The class Bar adds functionality to the class Foo (as well as redefining some of it). The interface Doer defines a "abstract base class" with no implementation at all. It however says, that any class that implements this interface _must_ conform to the interface. The class "MyDoer" is one such implementation. Suppose Foo goes in library "libFoo", then Bar should go in a callable library "libBar". The interface Doer is probably linked into "libBase", while the "MyDoer" should be put into a plug-in say "MyDoer". The reason for the later is, that all the application must know about the class MyDoer is that it implements the interface "Doer". There's a class of classes that doesn't really fit into the above scheme - especially in ROOT, but since they are all in principle callable, the implication is that they should go into a callable library and never be treated as plug-ins. Now, a plug-in can easily link against a callable library, but should never (and can't if done right) link against another plug-in. Callable libraries can (and should) easily link against all its dependent callable libraries. Using Autotools, this is done with the variable libFoo_LIBADD. > >> However, it is possible to configure a libset in such a way the build > >> system builds you the libraries but also executables (tools or a main > >> program). In fact, gled's main executable resides in > >> the GledCore libset. > > > > Fine, so you have a Java-like main class > > > > public class HelloWorld > > { > > public HelloWorld() { } > > public void run() > > { > > System.out.println("Hello, World"); > > } > > public static void main(String[] args) > > { > > HelloWorld h = new HelloWorld(); > > h.run(); > > } > > } > > > > It should still go in a run-time library since the developer may > > actually want to extend it. > > > > public class GoodbyeWorld extends HelloWorld > > { > > public GoodbyeWorld() {} > > public void run() > > { > > super.run(); > > System.out.println("Goodbye, World"); > > } > > public static void main(String[] args) > > { > > HelloWorld h = new GoodbyeWorld(); > > h.run(); > > } > > } > > > > The fact that the program it self is darn simple > > > > #include > > > > int main(int argc, char** argv) > > { > > gled::core::Main m(argc, argv); > > return m.Run(); > > } > > > > doesn't really change things - it's still a program. > > This is already done like that. The main base-class is called Gled, and its > sub-class GledGUI can be used to invoke the version with GUI. > The actual executables still contain some more code ... but it would be trivial > to put it in the classes themselves. I happen to like Java (very clean language/system), so I generally try to make my C++ look a little like it would in Java :-) Hence the example above. > >> This is practical, but complicates relationships between the build > >> system and packaging a wee little bit. > > > > How? > > > >> On the other hand, when used as a development framework and toolkit, > >> you need access to the helper scripts, > > > > Helper scripts, like gled-config, etc. can go in the libgled-dev > > package. > > So ... these should all be part of the GledCore? If you have other "libgled--dev" packages, you can put specialised scripts/data there. > Now we have a separate gled-build package that contains build helper-scripts and > serves as the environment for simultaneous work on several libsets. > This means, if I change something in GledCore, all dependant libsets will get > properly recompiled. Uh!? My main point is, that gled-config and it's siblings should _not_ go into gled-bin, since gled-bin is an end-user thing, and gled-config is a development thing. If you want a separate gled-build package, then fine, but I see little reason. > If we completely separate the build environment of each libset, the developer > would have to know what to rebuild ... in proper order. No. That's where Autotools comes in. Each package that links against something, should check if that something is available. How you do that, is up to you. A nice way is to use pkgconfig and have each libgled--dev package install scripts in /usr/lib/pkgconfig. This is how GTK+/Gnome does it. Other toolkits, like Globus, have decided to reinvent the wheel and make they own /etc/globus/pkg registry. I must _strongly_ discourage such a thing - it's cumbersome, error prone, and it's already done with pkgconfig - in a standarised way. Note, at runtime, the distribution will make sure that all needed dependencies are there, so you shouldn't worry about that all. > >> build environment, > > > > You should refrain from imposing a built environment on the developer. > > It won't work. Instead, provide stuff to be used for the most common > > build-systems (pkgconfig, m4 macros for Autotools, CMake stuff, and so > > on - and of course the obligatory gled-config :-). > > As I said above ... I think I could make this work for a single libset. > > >> libset libraries etc., > > > > If your "libsets" are truly plug-ins (i.e., conforming to an interface), > > then you do not need access to the libsets as development libraries. > > All you need, is the interface declaration. > > Well ... they are really libraries ... but they also contain bootstrap functions > that register the library contents into gled catalogs. As does any library linked in dynamically. > They also contain the > list of libsets they depend on ... so their bootstrap functions can be called > first (as libsets are linked against other libsets). Don't do that. Let the system resolve your dependencies for you - it's much better at it. The simple thing is simply to link your library against its dependants (the ROOT configure option --explicit-link does this). > >> and everything has to be set up in such a way that correct versions of > >> gled and root parts are used. > > > > There's no problem as long as you use so-version. If you try to link > > against a both gled libraries linked against ROOT version X, at the same > > time as you are linking against ROOT version Y, you will get errors. > > That said, you should use libtool to make the gled libraries depend on > > the ROOT libraries used at run-time. > > Wicked, yess. First I got parse-error, then went and read the libtool docs. > > So you do everything with libtool - compilation and linking. Yes, that's how Autotools does it to make sure things are consistent and what is needed is built. Note however, that it does not impose a particular built system on 3rd party developers. > > > >>>>> Other stuff, such as demos, cint files, textures (non-binaries): > >>>>> /usr/share/gled/{demos,...} > >>>>> > >>> Demos should go in /usr/share/doc/gled/demos. > >>> > >>> You should not distribute CINT generated dictionaries. There's no need, > >>> and the content is highly volatile. > >>> > >> If I get this correcty, you are suggesting the CINT generated > >> dictionaries should be recreated by the post-install script? > > > > No. The dictionaries are compiled into your libraries/plug-ins/... and > > there's no need for the end-user/developer to ever see these files. > > Simply do not distribute those files generated by rootcint/cint. > > The situation is slightly different in gled as project7 (gled's parser-codegen) > requires dumps from base libsets. Uh?!? > Now they are all contained in the top build > environment but I'm pretty sure I could make proper perl modules of them, put > them in /usr/share/gled/perllib and distribute them with libset-devel. It seems to me you're talking about "dictionaries" for Perl/Python/... not dictionaries for CINT (which becomes binary code). In that case, I refer you to the Debian Perl and Python policies. > >> On the other hand, what i would like to achieve is that a user on a > >> multiuser machine is able to select a version of gled and create a new > >> libset with it. > > > > Why? > > > > The system should provide _one_ and only one version of your package for > > development. If the user for some god-forsaken-reason needs an older > > version, she would have to put in the effort to install it herself. > > There's no reason to support more than one version of a given software > > package (how many versions of X do you have on your machine? How many > > versions of OpenOffice.org? Gimp? Emacs? Java?). > > > > gled is certainly not the only HEP application that thinks having > > multiple version of the same software on a single machine is a brillant > > idea. It is down right ridiculous. If your applications isn't > > stable/feature-rich enough that all users can use the latest release, > > then it does not belong in the system but in the sandboxes of the > > developers and interested users. > > Well ... if we're talking about root here ... I have 6 different versions on my > desktop :) four trunks, one branch off 5.18 (for cms) and one tagged version > (for alice). Why? Either you're doing direct development on ROOT, or you're just twisted (or both :-) Really, the ROOT API is stable enough that only one version should suffice. If not, the ROOT developers should be made aware of possible regressions. Anyways, once you have compiled your code against ROOT, you no longer need anything but the run-time libraries. > > Otherwise I agree. > > >> the new libset build directory should then be able to know on which > >> version it is supposed to build itself and be able to compile and > >> package itself. > > > > Why are you talking about libsets build themselves? Aren't you talking > > about making binary distributions? > > Yesss ... that's Jona's dream ... to have an easy way of starting your own > libset with the installed version of gled. Could you please explain a little what it is you are calling libsets, how they are used, and so on. I fear that I don't understand exactly what you're trying to do. > >> Ech, sorry, I thought it was done that way, but now I remember being > >> surprized at it when I first found out about it. I agree with you > >> completely - why remove some flexibility when you don't have to. But I > >> digress, and it is easy to be a critic. > > > > I've submitted many concrete proposals - all have gone ignored :-( > > Maybe we can try again after 5.22 is out ... this shouldn't be a major change, I > guess. There's the issue you also brought up - where to put the code. But it is solvable. I think the ROOT developers have the attitude "it seems to work fine for us, so why fix it?" > >>> The way to do this is simple. You make a singleton class that serves > >>> paths. The class can inspect the environment for specific settings if > >>> needed. For example > >>> > >>> #define PLUGIN_PATH "/usr/lib/gled/plugins" > >>> > >>> class PathManager { > >>> public: > >>> static PathManager& Instance() { > >>> if (!fgInstance) fgInstance = new PathManager; > >>> return fgInstance; > >>> } > >>> TString GetFromEnvOrPreset(const char* env, const char* preset) > >>> { > >>> TString ret; > >>> if (gSystem->Getenv(env)) > >>> ret = gSystem->Getenv(env); > >>> else > >>> ret = preset; > >>> return ret; > >>> } > >>> const char* GetPluginPath() const > >>> { > >>> if (fgPluginPath.IsEmpty()) > >>> fgPluginPath = GetFromEnvOrPreset("GLED_PLUGIN_PATH", PLUGIN_PATH); > >>> return fgPluginPath.Data(); > >>> } > >>> ... > >>> }; > >>> > >>> > >> Seems nice. Matevz? > > Aye, will make it so! > > But wait ... where does one put this? If it is in GledCore, it is already too > late. If it is in the executable, then the whole plugin loader should be there > as well, to load GledCore. Put the code in the library you need to link against anyways. I suspect you have some library that contains the definitions of basic stuff anyways. Yours, -- ___ | Christian Holm Christensen |_| | ------------------------------------------------------------- | | Address: Sankt Hansgade 23, 1. th. Phone: (+45) 35 35 96 91 _| DK-2200 Copenhagen N Cell: (+45) 24 61 85 91 _| Denmark Office: (+45) 353 25 447 ____| Email: cholm at nbi.dk Web: www.nbi.dk/~cholm | |