Branches
Releases
|
Version
|
Focus
|
Date
|
|
3.0
|
Major feature enhancements |
07-Aug-2008 03:51 |
|
2.18.3
|
Minor bugfixes |
30-Nov-2004 21:27 |
|
2.18.2
|
Minor bugfixes |
12-Nov-2004 06:27 |
|
2.18.1
|
Minor bugfixes |
12-Nov-2004 06:27 |
|
2.18
|
Major bugfixes |
12-Oct-2004 07:58 |
|
2.17
|
Minor feature enhancements |
01-Aug-2004 09:13 |
|
2.16
|
Minor security fixes |
08-Jul-2004 12:19 |
|
2.15
|
Major bugfixes |
06-Jul-2004 15:55 |
|
2.14
|
Minor bugfixes |
02-May-2004 12:14 |
|
2.13
|
Minor security fixes |
15-Apr-2004 12:21 |
Articles referencing this project
Comments
[»]
Makefile oversights
by Nigel Horne - May 3rd 2004 19:08:14
The Makefile doesn't support 'make uninstall' or 'make install-strip'
[reply]
[top]
[»]
Re: Makefile oversights
by Martin Pool - Jul 6th 2004 06:12:18
> The Makefile doesn't support 'make
> uninstall' or 'make install-strip'
I think uninstall is better handled through package management. It is
hard to do it reliably from a makefile.
[reply]
[top]
[»]
Re: Makefile oversights
by Nigel Horne - Jul 6th 2004 06:15:43
I take it that you agree that 'make install-strip' is
needed since you didn't say anything about it.
[reply]
[top]
[»]
Re: Makefile oversights
by Fergus Henderson - Jun 24th 2008 20:58:15
> The Makefile doesn't support 'make
> uninstall' or 'make install-strip'
distcc 3.0 supports 'make uninstall'.
See http://distcc.org
[reply]
[top]
[»]
force to do remotely
by igor2 - Jan 11th 2003 00:44:06
First of all, I really like distcc, it does distributed compiling better
than I ever expected from any distributed compiling stuff.
However, when I tried to use it for other purposes, I found out that
it done everything locally, since it wasn't sure that could be done
remotely. If there would be an option that would force distcc to do
a task remotely, that would not bother the original way of use, but
would make people able to do other things than compiling. Like running
cpu-intensive distributed mathematic calculations.
--
bye
Igor2
[reply]
[top]
[»]
Re: force to do remotely
by Martin Pool - Jan 12th 2003 01:30:38
I'm glad you like it. Thanks for saying so.
If I understand correctly, you'd like to use distcc to distribute tasks
other than C compilation across the network.
distcc has some domain-specific knowledge about C files that lets it
know how to distribute them across the network. For example, it needs to
know how to run the preprocessor locally so as to remove dependencies on
header files, and it needs to know which gcc options will conflict with
remote compilation. (This is different to systems like MOSIX, which don't
know anything about the tasks they're running, or dmake, which assumes
you'll have a shared filesystem by some other means.)
It would be possible to add similar intelligence for other "batch"
tasks that can be easily run remotely, such as perhaps compiling other
languages. Perhaps distcc could be the start of a framework for such
tools.
[reply]
[top]
[»]
Re: force to do remotely
by igor2 - Jan 12th 2003 02:40:48
...
> It would be possible to add similar
> intelligence for other "batch" tasks
> that can be easily run remotely, such as
> perhaps compiling other languages.
> Perhaps distcc could be the start of a
> framework for such tools.
Maybe an external "knowledge-base", as file(1) has magic(5), would be the
best solution.
--
bye
Igor2
[reply]
[top]
[»]
Re: force to do remotely
by Martin Pool - Jan 12th 2003 04:14:31
> Maybe an external "knowledge-base", as
> file(1) has magic(5), would be the best
> solution.
If it turned out that there was sufficient interest in other tasks
which fit within this general concept then some kind of scriptable system
would be good.
The task has to be something where it's completely determined by a
small number of input and output files, and by the command line. If this
is all that's needed, it may be simpler just to use rsh or ssh. distcc is
needed mostly because the input has to be preprocessed and checked before
being sent across. If it's a simpler task like for example sort
then just running it on some random machine will be sufficient.
[reply]
[top]
|
