[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-bindings
Subject: Re: [Kde-bindings] Twine2 (PyKDE* code generation tool) Naming
From: Shaheed Haque <srhaque () theiet ! org>
Date: 2015-04-06 18:00:10
Message-ID: CAHAc2jf+pRi6cBYJuYUP6D4de9_mbELTXpdoKZKx7vPuYLqRzw () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
The refactor sounds good.
As for a configuration file, you might care to look at the patch I posted
in the other thread for an alternative approach; its not quite right
because (a) IIRC the norm for KDE builds is for all the repos to be at the
same level and (b) the output ("build") directory is conventionally taken
as the current directory and (c) I'm a bit stuck becuase I just cannot seem
to make *anything* build.
If that does not suit, then I'd argue for overrides by passing args into
kf5.py. That could be run from cmake to end up with something that builds
like any other KDE package.
On 6 April 2015 at 17:45, Scott Kitterman <kde@kitterman.com> wrote:
> I've started looking at refactoring twine2 into a common module that can be
> used in (and shipped with) kf5 and the legacy KDE SC bindings. It seems
> reasonably tractable.
>
> I need a Python module name for the common module. I don't think twine2
> is a
> good name since twine is already in use for a popular tool on pypi:
>
> https://pypi.python.org/pypi/twine/1.5.0
>
> My intent, unless someone objects is to do the following:
>
> 1. Move all the current hard coded file locations to a configuration file
> to
> make it easier for everyone to use twine2 without having to edit source.
>
> 2. Move the non-binding specific code into a module with TBD name. It
> doesn't
> need to be pretty, just distinct, so I'm thinking perhaps ksipbindings, but
> I'd love better suggestions.
>
> 3. Refactor kf5.py, kdelibs.py, and kdeedu.py to use the module.
>
> 4. Add more command line options to make things generally more
> configurable.
>
> Does that sound OK? Is anyone else working on something that this would
> conflict with?
>
> Scott K
> _______________________________________________
> Kde-bindings mailing list
> Kde-bindings@kde.org
> https://mail.kde.org/mailman/listinfo/kde-bindings
>
[Attachment #5 (text/html)]
<div dir="ltr"><div><div>The refactor sounds good.<br><br></div>As for a configuration file, you might \
care to look at the patch I posted in the other thread for an alternative approach; its not quite right \
because (a) IIRC the norm for KDE builds is for all the repos to be at the same level and (b) the output \
("build") directory is conventionally taken as the current directory and (c) I'm a bit \
stuck becuase I just cannot seem to make *anything* build.<br><br></div>If that does not suit, then \
I'd argue for overrides by passing args into kf5.py. That could be run from cmake to end up with \
something that builds like any other KDE package.<br><div><br><br></div></div><div \
class="gmail_extra"><br><div class="gmail_quote">On 6 April 2015 at 17:45, Scott Kitterman <span \
dir="ltr"><<a href="mailto:kde@kitterman.com" target="_blank">kde@kitterman.com</a>></span> \
wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">I've started looking at refactoring twine2 into a common module that can \
be<br> used in (and shipped with) kf5 and the legacy KDE SC bindings. It seems<br>
reasonably tractable.<br>
<br>
I need a Python module name for the common module. I don't think twine2 is a<br>
good name since twine is already in use for a popular tool on pypi:<br>
<br>
<a href="https://pypi.python.org/pypi/twine/1.5.0" \
target="_blank">https://pypi.python.org/pypi/twine/1.5.0</a><br> <br>
My intent, unless someone objects is to do the following:<br>
<br>
1. Move all the current hard coded file locations to a configuration file to<br>
make it easier for everyone to use twine2 without having to edit source.<br>
<br>
2. Move the non-binding specific code into a module with TBD name. It doesn't<br>
need to be pretty, just distinct, so I'm thinking perhaps ksipbindings, but<br>
I'd love better suggestions.<br>
<br>
3. Refactor kf5.py, kdelibs.py, and kdeedu.py to use the module.<br>
<br>
4. Add more command line options to make things generally more configurable.<br>
<br>
Does that sound OK? Is anyone else working on something that this would<br>
conflict with?<br>
<br>
Scott K<br>
_______________________________________________<br>
Kde-bindings mailing list<br>
<a href="mailto:Kde-bindings@kde.org">Kde-bindings@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/kde-bindings" \
target="_blank">https://mail.kde.org/mailman/listinfo/kde-bindings</a><br> </blockquote></div><br></div>
[Attachment #6 (text/plain)]
_______________________________________________
Kde-bindings mailing list
Kde-bindings@kde.org
https://mail.kde.org/mailman/listinfo/kde-bindings
[prev in list] [next in list] [prev in thread] [next in thread]