[Kde-bindings] Twine2 (PyKDE* code generation tool) Naming

Scott Kitterman kde at kitterman.com
Mon Apr 6 20:57:41 UTC 2015


Will do.  Thanks.

I'm approaching twine2 as something that's Pythonic and not necessarily 
KDE/CMake like.  Once that's done, it's easy enough to add a CMake wrapper for 
people that prefer that (like was done with kapidox).

As far as location, my intent is to provide something that by default still 
works on Simon's machine, but is easy enough for the rest of us to change.  I 
think changing should be possible both with a modified configuration file and 
with command line overrides.

Scott K

On Monday, April 06, 2015 07:00:10 PM Shaheed Haque wrote:
> 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 at 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 at kde.org
> > https://mail.kde.org/mailman/listinfo/kde-bindings



More information about the Kde-bindings mailing list