Build system for KDE4

[Thiago Macieira]

Alexander Neundorf wrote:
>> flex and bison are pretty standard... They should be supported
>> out-of-the-box.
>
>I was also a bit surprised that cmake doesn't come with ready-built 
>flex/bison support. Since I have never used flex/bison myself until now 
please 
>tell me what has to be done with these files so I can provide a sample 
>implementation.

flex and bison/yacc are pre-compilers. That is, they parse an input file 
and generate a C or C++ source to be compiled.

The only annoying thing is that yacc always generates files with the same 
name, so you must rename the files.

In fact, I think GNU make has built-in rules for .y and .l files.

>>> The point here is: the tool should be able to read .pc files itself, 
>> without relying on running pkg-config and parsing the output. It should
>> be easy to write tests for those.
>
>I think this wouldn't be portable. Do they also exist on Mac OS X and 
>Windows ?

If you're testing with pkg-config for a package, it's quite likely the 
same package installed a .pc file somewhere on MacOS X and Windows. If it 
can't be found, you probably don't need it (example: xmms on Windows).

The fact is that pkg-config tests are the norm now on Linux (and other 
systems too, I guess) and we have tests for them. Better to standardise 
and make them fast than to leave the mess they are.

Of course, some packages install broken .pc files. Xmms, for instance, 
places ld flags inside its --libs, which makes unsermake choke. I've had 
to add code to parse the output and properly split the variables in a 
configure.in.in once.

>> If the tool helped with this, it would have to detect that (say)
>> kconfig_compiler is used, and must, therefore, be compiled twice: once
>> for the native tools, and once for the cross-compilation.
>
>Sounds complicated.

Right, which is why I'm inclined to agree with Waldo here: don't go there.

>What I forgot to mention:
>-in kdevelop/cmake you can find am2cmake, a script which converts
>Makefile.am's to cmake's CMakeLists.txt (the LD_ADD and LIB_ADD vars are
>still ignored, most other things work)

But can it parse Makefile.am? I'm interested in knowing if we can keep the 
existing files, because we wouldn't have the need to write a new parser 
for KDevelop and other tools.

Of course, if the Makefile.am syntax proves to be too cumbersome to be 
used, then never mind.

>-if you want to know more details about linking behaviour of cmake,
> consider subscribing to the cmake mailing list and contacting the
> developers directly (Thiago ?) They are usually very open for
> suggestion which improve cmake.

Maybe in the future. Right now, I'm overloaded with the mailing lists I am 
currently in (and falling behind on kde-bugs-dist).

>#just the stuff which implements enable-final
>MACRO(KDE_ADD_KPART _target_NAME )
>...
>  #if the option was enabled (e.g. in the cmake gui)
>  IF (KDE_ENABLE_FINAL)
>    #generate a file including all the source files
>    FILE(WRITE ${_target_NAME}_final.cpp "//autogenerated file\n")
>    FOREACH (_current_FILE ${_magic_SRCS})
>      FILE(APPEND ${_target_NAME}_final.cpp "#include
> \"${_current_FILE}\"\n") ENDFOREACH (_current_FILE)
>    #and create the library from this generated file
>    ADD_LIBRARY(${_target_NAME} MODULE  ${_target_NAME}_final.cpp)
>  #otherwise proceed as normal
>  ELSE (KDE_ENABLE_FINAL)
>    ADD_LIBRARY(${_target_NAME} MODULE ${_magic_SRCS} )
>  ENDIF (KDE_ENABLE_FINAL)
>...
>ENDMACRO(KDE_ADD_KPART _target_NAME)

This is one of the reasons I currently favour scons over cmake: the need 
to learn a new language (even if a simple, macro language). I already 
know a bit of Python, so scons gets points.
-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

4. And æfter se scieppend ingelogode, he wrát "cenn", ac eala! se 
rihtendgesamnung andswarode "cenn: ne wát hú cennan 'eall'. Ástynt."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20050614/5c16caad/attachment.sig>