I have also been struggling with the dependency problem, but haven't come up with a good solution as yet. (But I am still reading and learning about T2)
Rather than applications, my problem is just getting several basic tools to compile. It seems to come down to a ring of dependencies that require a bootstrap approach. The 'host' machine is the t2-trunk which uses gcc 4.4.2, gmp 4.3.1, ppl , and cloop_ppl. (But all virtual on Fedora 12) I am interested in creating a x86-64 architecture t2 platform and the current trunk system has difficulties finding the libraries for that cross architecture.. (Although I just now noticed a new libtool source was downloaded to my build engine. Maybe the problem is fixed.) ----- When you suggest 'changes' to the system, keep in mind that dependencies are a problem which has been approached cautiously over the years by many people, and the ./configure <options>; make; make install; process is firmly embedded. The programs Make, ant, etc, are all attempts to make things better. The fact that these schemes are all used means that there is no winner yet. Dependencies can come in through the <options> as well as being hard coded. If everyone in the world could do things in a standard way, that would also be helpful. It is like turning an oil tanker though. --- My 2 cents worth. Bob G On Tue, 2009-11-17 at 13:00 +0100, [email protected] wrote: > Dear All, > > Through the below observations I would like to generate a discussion > which I hope will speed up work on the quite complex dependency analysis > issue in T2 I am particularly interested in. > > Configuration of a certain package may have an impact on its > dependencies since certain options may refer to external packages, > libraries. For the same reason dependency analysis should be aware > not only of package names, but also the configuration of the packages > planned to be included. Picture could be even more complex if we include > the version numbers, but inside a chosen T2 tree consistency regarding > package version matrix can be assumed sparing so remarkble amount of > time and energy. > In T2 to each package is applied basically one configuration which is > supplemented eventually by settings derived from the selected target's > package matrix. I would call it deductive automatic way of configuration. > It is an excellent approach if the target is mature and one knows exactly > what packages (including dependencies) are needed. > Let us see what benefits may there be if we invert this approach I mean > starting from the conf matrix and solving dynamically the dependencies. > If we allow the package configuration to be splitted (this implies some > changes in the cache file's structure consequently) in optional > sections* [see endnote] (for instance AUTO [this is the actual conf], > COMPLETE, MINIMAL, TYPICAL, CUSTOM1, CUSTOM2, ...) making one > of them the default and make these section/config name enter the > "packages" file as a new field, we can fine tune, reconfigure the target > with minimal efforts evaluating each package's configuration (with relative > dependencies). Evaluation may be done by a script which (standalone, > but called optionally also at the end of the Config script) recursively > iterate through the package configurations appending to the "pkgsel" > file in config/$cfg_name the "X pkg_name" not yet included but needed. > In order to do that we need very accurate dependency infos: > which package(s!) are needed for which package's given conf option; > some dependency may have interchangeable packages, in which case we > need to check whether at least one of them is present if not the first > on the list should be used. > > Benefit: we can reduce the target's pkgsel to a couple of key > packages. Example: > > X abiword > X audacity > X apache > X lxde/* > > > if we allow to include conf section > on the same line of pkgsel, we can gain > further flexibility: > > X abiword > X audacity typical > X apache complete > X lxde/* minimal > > I hope the concept is clear enough for a discussion. > The weak part is the effective dependency list handling I guess. > Maybe someone has better idea on that... > > best regards, > > helasz > > > > * there is a pure bash readconf function which executes only the > commands line by line of a given section (see below). > So technically this solution may be integrated smoothly into T2. > > #!/bin/bash > > readconf() { > > match=0 > > while read line; do > # skip comments > [[ ${line:0:1} == "#" ]] && continue > > # skip empty lines > [[ -z "$line" ]] && continue > > # still no match? lets check again > if [[ $match == 0 ]]; then > > # do we have an opening tag ? > if [[ ${line:0:1} == "{" ]]; then > > # do we have a match ? > # if array is empty, only $1 and '*' is to be checked > if [ -n "${CONFSECTIONS[0]}" ] ; then > check_matches > else > check_match $1 > fi > continue > fi > > # found next opening tag after config was read - exit loop > elif [[ ${line:0:1} == "{" && $match == 1 ]]; then > # do we have a match ? > # if array is empty, only $1 and '*' is to be checked > if [ -n "${CONFSECTIONS[0]}" ] ; then > check_matches > else > check_match $1 > fi > continue > > # got a config line eval it > else > if ! [[ $line =~ ^[\ ]{0,}[\#\;] ]] ;then > if ! [[ $line =~ ^$ ]] ;then > eval "$line" > fi > fi > fi > > done < "$CONFIG_FILE" > } > > CONFIG_FILE=/path-to-pkg_conf/$pkg_name.conf > > # to execute commands in section "typical" > readconf "typical" > > > > ----------------------------------------------------------- > If you wish to unsubscribe from this mailing, send mail to > [email protected] with a subject of: unsubscribe t2 ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [email protected] with a subject of: unsubscribe t2
