Build system for KDE4
clee at kde.org
Tue Jun 14 06:46:57 BST 2005
On Mon, Jun 13, 2005 at 09:43:52PM -0700, David Johnson wrote:
> On Monday 13 June 2005 09:08 pm, Henry Miller wrote:
> > Perhaps at 43 it is time to prove you are not an old dog (I hope 43
> > isn't old, only 12 years away - with no idea where the time went in
> > getting this far I can't count 43 as far away) and learn a new trick.
> > Python is easy. It took me only a short time to love it.
> Actually, Ruby was on my list of things to learn. Unfortunately, the
> direction management is trying to make us go at work, the next thing on
> my list might have to be .NET/C#. I get the heebie jeebies just
> thinking about it...
If that sort of thing scares you, maybe it's time to start
looking for other work...
Trying to bring the discussion back on track here:
So the thing is, the language that the build system is
implemented in really shouldn't matter to 90% of our app
developers *anyway* because they're not going to be writing
custom extensions to the build system. How many people here have
written custom automake extensions, or hacked on acinclude.m4.in?
Not many, because 1) custom automake extensions are not
documented anywhere I can find, and 2) M4 is insanely hard to
grok, especially coming from C/C++-style languages.
What does matter is that we'll go from syntax like this:
bin_PROGRAMS = foo
foo_SOURCES = foo.cpp main.cpp
foo_LIBADD = $(LIB_KDEUI) $(LIB_KPARTS)
to syntax like (say, for scons/bksys):
foo_sources = """
fooenv.KDEprogram( "foo", foo_sources )
or (for CMake):
ADD_EXECUTABLE(foo foo.cpp main.cpp)
Out of those, the only one that looks slightly more programmatic
is scons/bksys, but it's not like it's so difficult to grasp that
it'd be impossible for new developers to pick up on it.
More information about the kde-core-devel