Image 01


M. L.

System Software 100 comments

Score 63.3%
Jun 09 2007
kconfigure, kinstall, kompare, klik etc...

There are simply too many DIFFERENT efforts going on trying to provide the same sort of
functionality or even the same sort of app (guess how many of such similar tools for other
window manager might exist)! And apparently some projects are not even aware of the other

That's BAD: open source is all about collaboration and not about cooking your own soup.

It should be possible to accomplish much more by uniting the manpower from all related
projects, so that these projects can be -functionality-wise- merged into a new fork
of all of these tools, ensuring that there is no unnecessary competition in an area
that has been successfully addressed on other platforms for decades already.

Apart from that, I truly like kompare-from its maintenance, UI and feature-richness point
of view, kompare is for sure the most advanced and promising utility in its category and
that's GREAT!

However, there are clearly some issues that -for the sake of kompare and its likely future
within KDE- should preferably be addressed, many of which were previously mentioned, but
some weren't yet-I would like to provide a number of enhancements and suggestions related
to turning kompile into a "software build manager":

- in certain situations, configuring a project requires pre-configuration:

some tarballs provide files specifically for this purpose, but
even if these are missing in the tarball itself, the autotools build files
can usually be re-created using autoconf, automake & co
It should be considered to provide optional support for "pre-configuration"
for packages that seem to make use of GNU autotools.

- configurable build directory location

in some situations it may make sense to use non-temporary build locations, that
may optionally not be deleted after installation

- repeated/incremental builds:

some projects may need to be regularly rebuild, so their folder must not be deleted

- decouple the configuration & build steps:

configuration is a step different from building: it doesn't necessarily
require root priviledges, nor will everybody usually/immediatley want to
run the build directly after the tarball's configuration: Steps that aren't
intertwined by default, should be properly separated and being dealt with
as separate entities. Some good suggestions related to kdesudo were already
made, in fact kconfigure also handles all steps separately.

- provide means to individually customize crucial configuration/build standard parameters and environment variables:

most scripts and tools used in the average linux/kde [GNU/autotools-based] tarball
use a predefined set of tools which usually supports a number of standard parameters
and honors certain environment variables (CC, CXX, CFLAGS, CXXFLAGS, LD_FLAGS,
LD_LIBRARY_PATH etc): advanced users may want to be provided with an overview of such
customizable attributes to show their contents and optionally edit/modify them, possibly
even allowing such users to save these settings in some sort of configuration/build profile.
This could for example be used to provide standard build profiles for use of ccache or distcc while

- provide means to customize non-standard parameters:

by running configure --help, the configure script's help can usually be obtained,
this could in turn be used to enable users to pass certain arguments to the script,
this could for example be based on coming up with a suggestion for the argument
name (retrieved from parsing the output), accompanied by a description/tooltip
coming from the description of the argument in the --help output, and then a
textbox/file picker dialog to optionally provide additional info, i.e. for cases
where additional information needs to be passed: ./configure --with-foo=path/to/foo

- interactive default mode while running kompile under KDE/X without arguments:

it might make sense to consider automatically going into interactive/GUI mode
when no parameter were provided, if the DISPLAY variable is set, you can assume
that X is available and anyone running kompile from a shell without arguments,
will probably want to start it in interactive mode, where the tarball can be chosen
from within the UI.

- build management/scheduler:

in some situations it may be desirable to postpone the compilation/build process of
a large -already configured- software project, thus it would be useful if there
was some sort of process (or even daemon) that could act as a build scheduler, which
would trigger builds based on certain criteria/conditions.
For example: I regularly rebuild large software packages such as kde, gcc and mozilla,
however I don't want this to interfere with my daily use of the machine, so I usually
postpone the build to take place at a time when I am not working at the machine, or
when the work/cpu load is really low.
Thus, it would be useful if there was a way to schedule builds to take place at a later time.
This could be based on certain factors, i.e. system load (reading directly from /proc or using
kde sensors).

- build priorities:

for users it would be useful to be able to configure priorities for each scheduled
build (high vs. low)

- build dependencies:

it is not unusual for developers to download a number of related tarballs which feature
mutual dependencies, thus for a software build manager it would make sense to provide
an abstract view of related tarballs, which may need to be configured/built in a certain
order, using information that may come from other projects. This would enable a scenario
where users may configure a number of tarballs to either "be" dependencies of another tarball,
or to provide dependencies to another tarball, so that kompile would be able to automatically
build related packages in a given order.

Again, thank you very much for an already very neat piece of software, and please consider the above ramblings only of advisory character, maybe other users could leave comments concerning these ideas, to help you assess what is generally considered useful and what isn't.

All the Best - Jan 02 2008