John Tytgat wrote:
In message <[email protected]>
Chris Palmer <[email protected]> wrote:
I would prefer that they stay - my plan was to get all the libraries
building successfully using build-libs (like Peter asked people to do a
month or so ago), then wipe my Debian install and start from scratch, so
I could see whether it's straightforward for anyone starting from
scratch to build all the libraries. However, the more packages that are
needed to build the libraries, the more cumbersome the main build script
becomes.
I guess there are three options here:
1. Keep it as is, perhaps with some more complicated system that
determines what packages have what programs and suggest the user install
those.
2. Remove the check from the build script and list the packages in a
file somewhere, so people can see what they need to have installed
before they start. The problem with this is that people may not be aware
of the list.
3. Move the build dependencies to each individual package, so that along
with a depends file in each package directory, there is also a
build-depends package which says what native tools you need installed.
This would reduce the automation of the build process somewhat, in that
the current method requires all the native tools installed before you
start, so that once that is done the entire build can (in theory)
proceed from start to finish without user input.
I'm in favour of 1, since it currently won't require as much maintenance
work as the other two, and won't require any work to set up, as it's
already there.
Any thoughts?
I like the intention but fear a bit the fallout for the occasional user or
newbie autobuilder. Perhaps the list should be splitted in two, the
ones we consider as vital and the others which are occationally needed
for building some packages.
If you miss the one of the former list, you get a build error; when you
miss one of the latter list, you get a warning at start of your build
that a build error later on might be due to missing build tools.
John.
That's a good possibility. The main issue with that is determining what
is vital and what is not. I guess one metric that could be used there is
the number of packages that need a build tool, or whether a library used
by several applications or other libraries needed that tool.
Another possible approach to this problem would be to add a flag to the
build scripts enabling the user to turn on or off the abort on missing
build tools check. We could default it to being on, and people who knew
what they were doing could turn it off. Or the reverse, if the majority
prefer it that way.
I've just struck yet another build tool dependency while running
build-libs (this time xaw3d needs imake), so I'd like some consensus on
the way forward, even if it is just to do nothing, or to continue adding
tools the way I was doing.
Chris.
_______________________________________________
GCCSDK mailing list [email protected]
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
