Yem, All,
Am 03.07.2013 18:30, schrieb Yann E. MORIN:
However, since you asked: your patches are numberedd 2 to 9. It seems
you considered the intro mail (the one I'm replying to here) as the
number one. Is that right, or is patch #1 missing?
[...]
You can achieve this using 'git send-email'. See:
git help send-email
I'm sorry for the missing first patch, actually I used git send-email, but
had initial problems with perl and its smtp module. I guess perl ate
this missing first patch mail, I'm not sure.
Nit-picking: please keep your mails and commit messages below 80-chars
per line, it's easier to read. Thanks! :-)
I will do my best :) One of my intentions to use git send-email was
because I thought it would automatically format patches in a way
that reviewing them would be easier. Likely I'm too much used, should I
say 'spoiled', by the github or gerrit review UI :)
I will change my proposed code accordingly.
I did not do any review of the patches, since I have a concern about the
series. It happens very often that, in enterprise ecosystems, the host
build machines are running rather aging distro, such as RHEL 5 (or even
RHEL 4 in some cases), so I think we still want the new kernels to be
buildable (and thus configurable) on such machines (eg. for
cross-compilation).
A serious concern, you're absolutly right. Let me tell you some
background information and my concerns regarding the current
code.
Although the Gtk2->3 port was less effort than the Qt-flavour port,
it is the more important one in my opinion. The current code definitly
does not compile with gtk3 and some used libraries (e.g. libglade)
are depreated for a while now.
Of just a cosmetic nature: In my experience, on newer systems
gtk2 applications additionally look somewhat outdated.
Maybe it is a good idea, to have the current gtk implementation
and the ported one side-by-side. What do you think?
Regarding the Qt-flavour port, I would classify it as an almost
complete rewrite. I'm more into C++/Qt and personally I always
used xconfig for kconf. The current implementation is more a Qt3
application that still compiles with Qt4 due of heavy usage of
the deprecated Qt3support layer. For the new implementation,
I adopted Qt4 techniques like the Qt MVC pattern
and the Qt interface designer (similar to the kconf-Gtk solution),
while paying attention to a Qt5 compatibilty.
It's more likely that I introducted bugs in this kconf flavour port,
of course. But I'd assume it's a good starting point for a discussion
of a more future-proof and probably more easy to maintain implementation.
Your concern about those aging distros certainly applies to this ported
kconf
flavour, too. So I'm not sure how to proceed. Options, I can thing of
are:
* Remove the Qt3/4-flavour and use the new Qt4/5 one, keep the Gtk2-flavour
for aging distros.
* Keep both Qt-flavour implementations (maybe with make targets like
xconfig and qconfig).
* Don't change the Qt3/4-flavour and do not introduce this proposed
Qt-flavour.
I would prepare a v2 patch series consisting of three patches only:
1) Directory structure. For each kconf ui flavour a separate one.
2) gtk3-flavour as side-by-side solution to the existing gtk2 one.
3) Qt4/5-flavour as side-by-side solution to the existing Qt3/4 one.
Far less intrusive :)
Those newer graphical kconfig flavours will be used by a project I'm involved in so
I will maintain it for the next couple of months.
Could you please explain what this project of yours is about?
* A configurable firmware for atmega processors (we are using the menuconfig
kconf interface only) [github: ethersex].
* CiAO: Highly configurable aspect oriented research operating-system.
Configuration
is realised by kconf. We are using the Qt interface mainly.
* And two other configurable operating systems, that are used for teaching.
I guess there are way more projects using the famous kconf and users who
like to use
the graphical interface flavours :)
PS. Sorry for not answering earlier, I had connection issues yesterday,
during all the evening & night. :-(
YEM.
So now it's my time to say sorry, took a few days to respond.
David.
--
To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
