From kde-core-devel  Wed Jun 15 01:40:55 2005
From: Thiago Macieira <thiago () kde ! org>
Date: Wed, 15 Jun 2005 01:40:55 +0000
To: kde-core-devel
Subject: Re: Build system for KDE4
Message-Id: <200506142241.02289.thiago () kde ! org>
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=111879967530473
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--nextPart1154798.EnMWXDlh9d"

--nextPart1154798.EnMWXDlh9d
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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=20
>flex/bison support. Since I have never used flex/bison myself until now=20
please=20
>tell me what has to be done with these files so I can provide a sample=20
>implementation.

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

The only annoying thing is that yacc always generates files with the same=20
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,=20
>> 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=20
>Windows ?

If you're testing with pkg-config for a package, it's quite likely the=20
same package installed a .pc file somewhere on MacOS X and Windows. If it=20
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=20
systems too, I guess) and we have tests for them. Better to standardise=20
and make them fast than to leave the mess they are.

Of course, some packages install broken .pc files. Xmms, for instance,=20
places ld flags inside its --libs, which makes unsermake choke. I've had=20
to add code to parse the output and properly split the variables in a=20
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=
=20
existing files, because we wouldn't have the need to write a new parser=20
for KDevelop and other tools.

Of course, if the Makefile.am syntax proves to be too cumbersome to be=20
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=
=20
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=20
to learn a new language (even if a simple, macro language). I already=20
know a bit of Python, so scons gets points.
=2D-=20
  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 =E6fter se scieppend ingelogode, he wr=E1t "cenn", ac eala! se=20
rihtendgesamnung andswarode "cenn: ne w=E1t h=FA cennan 'eall'. =C1stynt."

--nextPart1154798.EnMWXDlh9d
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQBCr4cuM/XwBW70U1gRAlEUAKDBT9D0eenEFY4u6rhtu+72ZW3s7ACgjJF1
3qMkSLEzs9d2n2y2JBfGdaE=
=gTgL
-----END PGP SIGNATURE-----

--nextPart1154798.EnMWXDlh9d--