Hasso Tepper wrote:
>getservbyname_r, getprotobyname_r and getservbyport_r symbols exist in
>NetBSD libc for binary compatibility, but no declaration in headers, so
>they can't be used for compiling. AFAICS only symbol in library is
>checked at the moment (check_function_exists), but it isn't enoug
autoconf used to always generate and reuse a config.cache, and then they
changed the default
so that the user had to specify --cache explicitely instead, presumably because
many people
didn't find out that they had to remove their config.cache after installing a
library or changing
whatever else
Hi,
shouldn't it be renamed to add_include_directories to make clear that it
adds/appends directories.
Cheers,
André
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Hi,
I'm speaking about the following variables:
CMAKE_CURRENT_BINARY_DIR
CMAKE_CURRENT_SOURCE_DIR
CMAKE_SOURCE_DIR
First the prefix is a bit confusing as one could mean these are CMake
directories and second it's less to type :-)
Cheers,
André
___
K
Personally I use cmake CVS, but for those using the tarball, they need this fix
which makes CMAKE_INCLUDE_CURRENT_DIR work also for srcdir==builddir.
(This is a diff between the 2.3.4 tarball and CVS, at least my last update of
it)
--- ../../tmp/cmake-2.3.4-20060317/Source/cmLocalGenerator.cxx
On Monday 27 March 2006 14:19, André Wöbbeking wrote:
> Hi,
>
> I'm speaking about the following variables:
>
> CMAKE_CURRENT_BINARY_DIR
> CMAKE_CURRENT_SOURCE_DIR
> CMAKE_SOURCE_DIR
>
> First the prefix is a bit confusing as one could mean these are CMake
> directories and second it's less to
At 05:53 AM 3/27/2006, David Faure wrote:
>autoconf used to always generate and reuse a config.cache, and then they
>changed the default
>so that the user had to specify --cache explicitely instead, presumably
>because many people
>didn't find out that they had to remove their config.cache after
At 07:19 AM 3/27/2006, André Wöbbeking wrote:
>Hi,
>
>I'm speaking about the following variables:
>
>CMAKE_CURRENT_BINARY_DIR
>CMAKE_CURRENT_SOURCE_DIR
>CMAKE_SOURCE_DIR
>
>First the prefix is a bit confusing as one could mean these are CMake
>directories and second it's less to type :-)
The idea
Perhaps we should wait a bit to collect up a few more issues before making a new
tar ball. We could say in-source builds are currently broken. In fact, I see
almost
no point in using them at all. In many of our projects we just do not allow
them.
We put a check in the cmake files that issues a
On Monday 27 March 2006 15:59, William A. Hoffman wrote:
> Perhaps we should wait a bit to collect up a few more issues before making a
> new tar ball.
Makes sense.
> We could say in-source builds are currently broken. In fact, I see almost
> no point in using them at all. In many of our pro
At 09:05 AM 3/27/2006, David Faure wrote:
>On Monday 27 March 2006 15:59, William A. Hoffman wrote:
>> Perhaps we should wait a bit to collect up a few more issues before making a
>> new tar ball.
>Makes sense.
>
>> We could say in-source builds are currently broken. In fact, I see almost
>> n
On Monday 27 March 2006 16:12, William A. Hoffman wrote:
> At 09:05 AM 3/27/2006, David Faure wrote:
> >On Monday 27 March 2006 15:59, William A. Hoffman wrote:
> >> Perhaps we should wait a bit to collect up a few more issues before making
> >> a new tar ball.
> >Makes sense.
> >
> >> We could
William A. Hoffman wrote:
> The more general solution is to put the directories in CMake
> in Modules/Platform/UnixPaths.cmake. Then all the FIND stuff in
> cmake will use them.
>
> If you could try it and make sure it works, I can commit the changes
> you make to cmake.
Patch attached. Note that
Thiago Macieira wrote:
> Hasso Tepper wrote:
> >getservbyname_r, getprotobyname_r and getservbyport_r symbols exist in
> >NetBSD libc for binary compatibility, but no declaration in headers,
> > so they can't be used for compiling. AFAICS only symbol in library is
> > checked at the moment (check_f
Hasso Tepper wrote:
>Thiago Macieira wrote:
>> Hasso Tepper wrote:
>> >getservbyname_r, getprotobyname_r and getservbyport_r symbols exist
>> > in NetBSD libc for binary compatibility, but no declaration in
>> > headers, so they can't be used for compiling. AFAICS only symbol in
>> > library is che
At 09:53 AM 3/27/2006, Hasso Tepper wrote:
>William A. Hoffman wrote:
>> The more general solution is to put the directories in CMake
>> in Modules/Platform/UnixPaths.cmake. Then all the FIND stuff in
>> cmake will use them.
>>
>> If you could try it and make sure it works, I can commit the changes
William A. Hoffman wrote:
> At 09:53 AM 3/27/2006, Hasso Tepper wrote:
> >Patch attached. Note that actually very few platforms include
> > UnixPaths. Maybe it's good idea to include it for other *BSD
> > platforms and all commercial unixes as well? ;)
>
> Thanks, and good point. I have applied th
At 11:00 AM 3/27/2006, you wrote:
>William A. Hoffman wrote:
>> At 09:53 AM 3/27/2006, Hasso Tepper wrote:
>> >Patch attached. Note that actually very few platforms include
>> > UnixPaths. Maybe it's good idea to include it for other *BSD
>> > platforms and all commercial unixes as well? ;)
>>
>> T
On 3/26/06, William A. Hoffman <[EMAIL PROTECTED]> wrote:
> At 04:27 PM 3/26/2006, David Faure wrote:
> >Ah. In that case, maybe you could add /sw/include and /sw/lib as well,
> >for Mac OS X (fink)? For now I passed those paths on the cmake command line
> >when compiling on the mac, but AFAIK thos
On Monday 27 March 2006 18:26, Laurent Montel wrote:
> + ${CMAKE_SOURCE_DIR}/kspread/dialogs/kspread_dlg_angle.cc
You might want to try just "dialogs/kspread_dlg_angle.cc" instead. I think it
works, it's
shorter and more prepared for moving things around. I'm not sure why Alex used
absolute
I can't find it on a quick glance in the cmake docs... how do I create a
symlink on installing?
(e.g. we need it for "ln -s crystalsvg default.kde").
Hmm, is this not available because windows doesn't support it?
--
David Faure, [EMAIL PROTECTED], sponsored by Trolltech to work on KDE,
Konquero
At 11:30 AM 3/27/2006, Tanner Lovelace wrote:
>On 3/26/06, William A. Hoffman <[EMAIL PROTECTED]> wrote:
>> At 04:27 PM 3/26/2006, David Faure wrote:
>> >Ah. In that case, maybe you could add /sw/include and /sw/lib as well,
>> >for Mac OS X (fink)? For now I passed those paths on the cmake command
At 12:56 PM 3/27/2006, David Faure wrote:
>I can't find it on a quick glance in the cmake docs... how do I create a
>symlink on installing?
>(e.g. we need it for "ln -s crystalsvg default.kde").
${CMAKE_COMMAND} -E create_symlink old new
>Hmm, is this not available because windows doesn't supp
On Monday 27 March 2006 20:04, William A. Hoffman wrote:
> At 12:56 PM 3/27/2006, David Faure wrote:
> >I can't find it on a quick glance in the cmake docs... how do I create a
> >symlink on installing?
> >(e.g. we need it for "ln -s crystalsvg default.kde").
>
> ${CMAKE_COMMAND} -E create_symlin
On Monday 27 March 2006 18:47, David Faure wrote:
> On Monday 27 March 2006 18:26, Laurent Montel wrote:
> > + ${CMAKE_SOURCE_DIR}/kspread/dialogs/kspread_dlg_angle.cc
>
> You might want to try just "dialogs/kspread_dlg_angle.cc" instead. I think
> it works, it's shorter and more prepared for
On Monday 27 March 2006 20:04, William A. Hoffman wrote:
> At 12:56 PM 3/27/2006, David Faure wrote:
> >I can't find it on a quick glance in the cmake docs... how do I create a
> > symlink on installing? (e.g. we need it for "ln -s crystalsvg
> > default.kde").
>
> ${CMAKE_COMMAND} -E create_symlin
Hi,
we have several different types of applications with different requirements
for the RPATH:
1) "normal" GUI applications - on OS X frameworks should be generated, RPATH
to the install dir
2) non-GUI applications (e.g. kde-config) - no frameworks on OS X, RPATH to
the install dir
3) tools
On Monday 27 March 2006 14:19, André Wöbbeking wrote:
> Hi,
>
> I'm speaking about the following variables:
>
> CMAKE_CURRENT_BINARY_DIR
> CMAKE_CURRENT_SOURCE_DIR
> CMAKE_SOURCE_DIR
>
> First the prefix is a bit confusing as one could mean these are CMake
> directories and second it's less to type
On Monday 27 March 2006 14:22, André Wöbbeking wrote:
> Hi,
>
> shouldn't it be renamed to add_include_directories to make clear that it
> adds/appends directories.
I don't think the cmake developers will start to change the commands without
good reason (at least I wouldn't do it).
Bye
Alex
--
On Monday 27 March 2006 16:27, David Faure wrote:
> On Monday 27 March 2006 16:12, William A. Hoffman wrote:
> > At 09:05 AM 3/27/2006, David Faure wrote:
> > >On Monday 27 March 2006 15:59, William A. Hoffman wrote:
> > >> Perhaps we should wait a bit to collect up a few more issues before
> > >>
Alexander Neundorf wrote:
>Maybe 2) and 4) should be considered the same.
Makes sense.
>1) - no keyword required, it's the default
>2) - NOGUI
>3) - "BUILDONLY", "BUILDHELPER", "HELPER", "LOCAL" ?
>4) - either merge with 2) or "BUILDTOOL" or something
NOGUI would help for #4
I'd say BUILDONLY f
At 02:26 PM 3/27/2006, Alexander Neundorf wrote:
>> > project(kdelibs)
>> > #
>> > # Disallow in-source build
>> > STRING(COMPARE EQUAL "${kdelibs_SOURCE_DIR}"
>> > "${kdelibs_BINARY_DIR}" INSOURCE)
>> > IF(INSOURCE)
>> >
On Monday 27 March 2006 15:36, William A. Hoffman wrote:
> At 07:19 AM 3/27/2006, André Wöbbeking wrote:
> >Hi,
> >
> >I'm speaking about the following variables:
> >
> >CMAKE_CURRENT_BINARY_DIR
> >CMAKE_CURRENT_SOURCE_DIR
> >CMAKE_SOURCE_DIR
> >
> >First the prefix is a bit confusing as one could
On Monday 27 March 2006 21:24, Alexander Neundorf wrote:
> On Monday 27 March 2006 14:22, André Wöbbeking wrote:
> > Hi,
> >
> > shouldn't it be renamed to add_include_directories to make clear
> > that it adds/appends directories.
>
> I don't think the cmake developers will start to change the com
Slight correction on terminology below...
On 3/27/06, Alexander Neundorf <[EMAIL PROTECTED]> wrote:
> 1) "normal" GUI applications - on OS X frameworks should be generated, RPATH
> to the install dir
s/frameworks/application bundles/
Explanation: "Frameworks" on OS X are library bundles. Appli
On Monday 27 March 2006 22:15, Tanner Lovelace wrote:
> Slight correction on terminology below...
>
> On 3/27/06, Alexander Neundorf <[EMAIL PROTECTED]> wrote:
> > 1) "normal" GUI applications - on OS X frameworks should be generated,
> > RPATH to the install dir
>
> s/frameworks/application bundle
At 03:21 PM 3/27/2006, Alexander Neundorf wrote:
>On Monday 27 March 2006 22:15, Tanner Lovelace wrote:
>> Slight correction on terminology below...
>>
>> On 3/27/06, Alexander Neundorf <[EMAIL PROTECTED]> wrote:
>> > 1) "normal" GUI applications - on OS X frameworks should be generated,
>> > RPATH
Hi, the attached patch fixes problems i had with cmake not searching my
correct libkdecore.so, (it found kde3 libkdecore on /usr/lib64) i think the
patch is correct, because if you have kdelibs outside what
KDE4_LIB_INSTALL_DIR says you are in deep trouble.
As a suggestion i think it could be
On 3/25/06, Thiago Macieira <[EMAIL PROTECTED]> wrote:
> Tanner Lovelace wrote:
> >For windows, I noticed there were two variables, so
> >I setup Q_WS_WIN32 and Q_WS_WIN64.
>
> Q_WS_WIN is also defined in those cases. (as well as Q_OS_WIN)
Excellent! Then, here's a new patch, diffed against what
On Monday 27 March 2006 14:26, Alexander Neundorf wrote:
> Hopefully this doesn't mess up the builds of too many people (which were
> building in-source previously and had the files created there, but now have
> to build out-of-source with the old generated files still around in the
> source dir...
40 matches
Mail list logo
