| 1 |
"Jerry A!" wrote: |
| 2 |
> |
| 3 |
> On Fri, Apr 13, 2001 at 01:40:17AM -0600, Pete Gavin wrote: |
| 4 |
> : |
| 5 |
> : I've been looking at SWIG a bit, and I think it would be really |
| 6 |
> : helpful for this stuff. That way, we might eventually be able to make |
| 7 |
> : it so that most portage stuff is also available from perl, and anyone |
| 8 |
> : who wants to access portage from perl may do so easily. (I know some |
| 9 |
> : of you may cringe at this, but I happen to like perl :) but don't |
| 10 |
> : worry, I like python equally... both have their uses) |
| 11 |
> |
| 12 |
> Curiousity on my part. Is there any reason why we're looking to step |
| 13 |
> away from python? It appears as though the Linux/Python connection are |
| 14 |
> here to stay. Especially with ESR's new CML2 project. |
| 15 |
|
| 16 |
Gimme a link to that project please. |
| 17 |
|
| 18 |
As we go |
| 19 |
> forward, one won't even be able to rebuild the kernel w/out Python. |
| 20 |
> |
| 21 |
> Achim, have you looked at the freeze module for compiling the python |
| 22 |
> bits for the embedded devices you're working on (instead of rewriting |
| 23 |
> them in C++)? |
| 24 |
|
| 25 |
No, can I make binaries for python scripts with that? The problem I see |
| 26 |
for embedded |
| 27 |
devices, is that python requires simply too much memory. If it is |
| 28 |
possible to make standalone |
| 29 |
binaries that do eighter require all the python modules nor the python |
| 30 |
binarie, I would be intersted |
| 31 |
how huge such a binary will be. |
| 32 |
|
| 33 |
We had a discussion about allowing other languages like perl or tcl/tk |
| 34 |
to be used for ebuild. And decided that |
| 35 |
it makes more sense converting stable parts of python code to c++. Once |
| 36 |
it's all c++ we can make modules |
| 37 |
for other scripting languages. I personal prefer perl as a scripting |
| 38 |
language and did not investigate much |
| 39 |
time in learning python. But as long as daniel is the developer of |
| 40 |
ebuild it is his right do choose his |
| 41 |
preferend language for development I think. |
| 42 |
Our biggest problem is still that we can not spend all our time in |
| 43 |
gentoo development as long as we do not have |
| 44 |
sponsors. |
| 45 |
|
| 46 |
There is a install-gui in development that will use qt first, but it |
| 47 |
will be designed in a manner that the gui |
| 48 |
parts are separated from the configuration backend, so it should be easy |
| 49 |
to write ncurses or gtk frontends too. |
| 50 |
But do not expect that stuff next week. :-) |
| 51 |
|
| 52 |
BTW: Jerry, are you still headbanging or did you get gentoo working now? |
| 53 |
|
| 54 |
achim~ |
Archives