Yann, All,
I've checked your kconfig-frontends project [0] and very much liked your
restructuring of the kconfig dir. What's the reason not to "upstream" this
structure?
Actually the root Makefile of the kconfig dir still offer the same
targets, so
no "legacy" or out of tree applications should be affected negativly. Am I
missing something?
[0]http://ymorin.is-a-geek.org/projects/kconfig-frontends
Am 04.08.2013 13:02, schrieb Yann E. MORIN:
I prepared a rebased V2 of the patchset. As far as I get the consensus
is to replace the existing Qtk and Qt flavours because there exist a
^^^
Qtk, a new toolkit as a merge of Gtk and Qt? ;-)
Wouldn't that be awesome :D
Anyway, I like how you cleaned up scripts/kconfig by moving frontends to
their own sub-dir.
/me wonders how much kconfig-frontends [0] will be impacted by this
reordering...
I've tested all available frontends after my move-into-subdir
changes (n-/menu-/g-/xconfig). I had to fix some include paths in the
first commit, but big changes regarding to your project
only affect the gconf/qconf dirs.
Different from the kernel kconf, you have used special autotool rules like
AM_V_MOC etc for Qt, I didn't know those exist.
You want to send patches to the list for people to review them and
comment. You don't use pull-requests for this, since the pull-request
only contains a single mail [1] with the URL to pull from.
Once everything is OK, either the maintainer will apply those patches,
or a sub-maintainer will do it and send a pull-request for 'big' series.
So, you did well to send patches.
Ok, understood :)
Regards,
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
