Im trying to compile Kompile under arch linux 64 and I'm getting these errors:

main.cpp: In function ‘int main(int, char**)’:
main.cpp:96: error: ‘exit’ was not declared in this scope
main.cpp:104: error: ‘exit’ was not declared in this scope
main.cpp:127: error: ‘exit’ was not declared in this scope
main.cpp:151: error: ‘exit’ was not declared in this scope
main.cpp:251: error: ‘exit’ was not declared in this scope
main.cpp:275: error: ‘exit’ was not declared in this scope
main.cpp:283: error: ‘exit’ was not declared in this scope
main.cpp:294: error: ‘exit’ was not declared in this scope
main.cpp:309: error: ‘exit’ was not declared in this scope
main.cpp:332: error: ‘exit’ was not declared in this scope
main.cpp:345: error: ‘exit’ was not declared in this scope
make[2]: *** [main.o] Error 1
make[2]: Leaving directory `/home/bran/builds/kompile/src/kompile-0.3-beta3/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/bran/builds/kompile/src/kompile-0.3-beta3'
make: *** [all] Error 2
==> ERROR: Build Failed.
Aborting...

I have downloaded stable version and I installed it (using ./configure, make, make install). But when I want to try to run it, an error shows and says :
"You have forgot to specify a valid sources tarball or specified file isn't a valid sources tarball!
Specify an existing and valid source tarball please.
Maual selection of sources tarball and building options manual setup will be avaiable in future version."

What does it mean? What's the problem and solution?

Thanks..

Ok.. No problem.

I always get this error:

libtool: link: cannot find the library `/usr/lib/libfam.la'

I run Mandriva Powerpack 2008.0 64bit

I tried running the RPM but nothing happens.

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
ones!?

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 autogen.sh 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
building.

- 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

Are there any plans to implement support for programs that use setup.py for their installation? (And if so, would it be possible to make it so said programs could be uninstalled by Kompile even if the setup.py file doesn't include a rule for uninstalling?) That's the only thing I find lacking. Otherwise, keep up the great work! :-)

Hi,
I used this app in its beta2 version.
Unfortunately this link http://www.kde-apps.org/content/download.php?content=30223&id=4 lets us download a tar.gz-file, which is impossible to be extracted as expected with Ark for instance. The extraction process results in numerous errors: ...Couldn't open file. Permission denied. Then follows a general error: Extraction failed.
So my question is: where can we find a proper tar.gz for this wonderful beta3? (I went back to beta2)
Thanks in advance.

Hi,
probably there was been an error during tarball creation.
I've uploaded a new tarball which should work.

Great idea. This could really help new Linux users adjust to this wonderful OS.

If you want to get the source try:
http://archive.ubuntu.com/ubuntu/pool/universe/k/kompile/kompile_0.3~beta2.orig.tar.gz

Nice program. Is it still under development?

Feature request:
Better integration with checkinstall. Add a configuration dialog providing settings such as name, maintainer, version, description etc.

If you implement the above you can (optionally) try to get some of the info from the distribution, if that program already exists in a repository.
e.g. you can parse the output of "apt-cache show PACKAGENAME" and get the description and the dependencies.

This program should have been written a decade ago.

http://packages.ubuntulinux.org/edgy/kde/kompile

you can find it here

the links is broken..
what method do you use to keep track of installed files?

I like to see Kompile that it creates .deb/.rpm etc - packages and then installs them instead of the source-tarball.
The advantage is that you could remove the packages with a package manager.

.deb-packages are made and installed with:

./configure
make
sudo checkinstall -D make install

I do not know how .rpm's are made.

Hi.

For those you are trying to find the Kompile RPMs for SUSE 10.1 you can find them here: http://www.carlos.pinguix.com/suse/10.1/ (src, i586 and debuginfo packages available)

For now on Kompile RPM for SUSE and openSUSE can be found here: http://software.opensuse.org/download/KDE:/Community/

Every time I download a package from KDE-Apps and see it has a compile script via the tbz or tgz kio, I try kompile on it. Even I know how to deal with a term, I must admit this kompile way is much more comfortable. Althoug it takes a larger amount of time to compile apps compared to doing it on a terminal.

This doesn't work for me, complains about missing kdelibs4c2 although it is installed. Link to a non-beta version would be appreciated.

this is a very neat and handy app here. saves you a lot things by doing tarball installs. this is very minor but please make a fix of this app's frames. somehow you have to resize it coz the buttons/widgets don't fit into it. otherwise it's great.. .

thanks! 2 thumbs up!

i'm trying to compile Kompile on my 64-bit machine and i get an error. it's about a "qt-mt" library that it can't seem to find. i have the KDE version that comes with SUSE 10.1. i think it's kde 3.5.1. i'm able to compile other source packages though.

what package is this BTW? i can't seem to find it.

has this project been discontinued? it's been a while since an update.

i'm unable to make new profiles in 3beta2
when i try to do it with "modify" and than "save profile" it says profile has no name but i have no place to put the name

I was waiting for something like this to come along.
I hope KDE get behind this and supports you. Particulary when I´ve tried installing it on Mandriva 2005 LE and met dependancy hell and given up in disgust. It would be great to see included with KDE as a package.

Keep up the good work.

I have corrected nearly all the bugs reported and now I'm working on performance.
I'm trying to understand to us why v0.3 is more slower than v0.2. The only change to "install engine" form v0.2 to v0.3 is switch from QProcess to KProcess classes for building commands's execution.
Thanks to all for reports and patience ;-)