Re: playground/devtools/kdevelop4-extra-plugins/python/parser
On 10.07.07 22:01:30, Alexander Neundorf wrote:
On Tuesday 10 July 2007 16:08, Andreas Pakulat wrote:
...
I think the macro I came up with causes a full rebuild of the project
using it when touching any of the CMakeLists.txt.
An example is playground/devtools/kdevelop4-extra-plugins/ruby
if I touch tests/CMakeLists.txt the whole project is rebuilt, the
generated and non-generated files are all recompiled.
The macro I use looks like this:
macro(GET_GENERATED_SRCS _srcsList)
if(KDEVPG_FOUND AND FLEX_FOUND)
include_directories(${KDEVPG_INCLUDE_DIR})
kdevpg_generate(_kdevpgList ruby DEBUG_VISITOR
${CMAKE_SOURCE_DIR}/parser/ruby.g
${CMAKE_SOURCE_DIR}/parser/ruby_lexer.h)
# Copy ruby_lexer.ll to the builddir, so that flex doesn't write
out # absolute paths in the generated file when we pass them as arguments.
# In short, I don't want stuff like
# '#line 2 /home/kde/build/.../ruby_lexer.cpp in SVN.
add_custom_command(
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/ruby_lexer.ll
MAIN_DEPENDENCY ${CMAKE_SOURCE_DIR}/parser/ruby_lexer.ll
COMMAND ${CMAKE_COMMAND} ARGS -E copy_if_different
${CMAKE_SOURCE_DIR}/parser/ruby_lexer.ll
${CMAKE_CURRENT_BINARY_DIR}/ruby_lexer.ll
)
# Add command to generate the lexer.
add_custom_command(
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/ruby_lexer.cpp
MAIN_DEPENDENCY ${CMAKE_CURRENT_BINARY_DIR}/ruby_lexer.ll
DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/ruby_parser.h
${CMAKE_SOURCE_DIR}/parser/ruby_lexer.h
COMMAND ${FLEX_EXECUTABLE}
ARGS-oruby_lexer.cpp
ruby_lexer.ll
WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
)
set(${_srcsList} ${_kdevpgList}
${CMAKE_CURRENT_BINARY_DIR}/ruby_lexer.cpp) else(KDEVPG_FOUND AND
FLEX_FOUND)
include_directories(${CMAKE_SOURCE_DIR}/parser/generated)
message(STATUS Assuming existence of generated parser files)
message( STATUS Assuming existence of generated lexer files)
set(${_srcsList}
${CMAKE_SOURCE_DIR}/parser/generated/ruby_parser.cpp
${CMAKE_SOURCE_DIR}/parser/generated/ruby_visitor.cpp
${CMAKE_SOURCE_DIR}/parser/generated/ruby_default_visitor.cpp
${CMAKE_SOURCE_DIR}/parser/generated/ruby_lexer.cpp )
endif(KDEVPG_FOUND AND FLEX_FOUND)
endmacro(GET_GENERATED_SRCS)
Ok, not sure what is causing this.
btw, I only need to run make, not even touching anything to make it do a
full rebuild.
You should be able to merge the two add_custom_command()s into one as below:
macro(GET_GENERATED_SRCS _srcsList)
if(KDEVPG_FOUND AND FLEX_FOUND)
include_directories(${KDEVPG_INCLUDE_DIR})
kdevpg_generate(_kdevpgList ruby DEBUG_VISITOR
${CMAKE_SOURCE_DIR}/parser/ruby.g
${CMAKE_SOURCE_DIR}/parser/ruby_lexer.h)
It turns out the problem is this macro: kdevpg_generate and it also
turns out that I'm too stupid to run make install/fast after fixing an
error. So the reason is the macro looks like this (in the install dir):
macro(KDEVPG_GENERATE _srcVar _language )
set(_depList ${ARGN})
list(GET _depList 0 _ns)
set(_namespace ${ARGV1})
if( ${_ns} STREQUAL NAMESPACE )
list(GET _depList 1 _namespace)
list(REMOVE_AT _depList 0 1)
endif( ${_ns} STREQUAL NAMESPACE )
list(GET _depList 0 _dbg)
set(_dbgVisit)
if( ${_dbg} STREQUAL DEBUG_VISITOR )
list(REMOVE_AT _depList 0)
set(_dbgVisit --debug-visitor)
endif(${_dbg} STREQUAL DEBUG_VISITOR )
list(GET _depList 0 _grammarFile)
list(REMOVE_AT _depList 0)
if(NOT _grammarFile)
message(ERROR No grammar file given to KDEVPG_GENERATE macro)
endif(NOT _grammarFile)
add_custom_command(
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/${_language}_ast.h
${CMAKE_CURRENT_BINARY_DIR}/${_language}_parser.h
${CMAKE_CURRENT_BINARY_DIR}/${_language}_parser.cpp
${CMAKE_CURRENT_BINARY_DIR}/${_language}_visitor.h
${CMAKE_CURRENT_BINARY_DIR}/${_language}_visitor.cpp
${CMAKE_CURRENT_BINARY_DIR}/${_language}_default_visitor.h
${CMAKE_CURRENT_BINARY_DIR}/${_language}_default_visitor.cpp
MAIN-DEPENDENCY ${_grammarFile}
#^^^ Note that this is not an underscore as it should be
DEPENDS ${_depList}
COMMAND ${KDEVPG_EXECUTABLE}
ARGS--output=${_language} --namespace=${_namespace}
${_dbgVisit} ${_grammarFile}
WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
)
set( ${_srcVar}
${CMAKE_CURRENT_BINARY_DIR}/${_language}_parser.cpp
${CMAKE_CURRENT_BINARY_DIR}/${_language}_visitor.cpp
Re: playground/devtools/kdevelop4-extra-plugins/python/parser
On 09.07.07 23:22:23, Alexander Neundorf wrote:
On Monday 09 July 2007 14:22, Andreas Pakulat wrote:
python/parser/CMakeLists.txt with
add_executable(python-parser ${foo_SRCS} )
Then cmake will complain that it doesn't know how to create the files in
foo_SRCS for the python-parser target.
And always setting the foo_SRCS GENERATED in the subdirs is not really
usable either as they are only generated when you've got the generator
tool installed (which is not required). So I'd again need to have
if(FOO_FOUND) stuff everywhere.
Can you put the rules for generating the files in the directories where the
file are used, e.g. with some macros ?
Hmm, can you have a look at the attached file please? Calling the macro
doesn't execute the custom command and thus the files are not generated.
Andreas
--
You shall be rewarded for a dastardly deed.
#To properly find kdevelop-pg add -DKDEVPG_DATA_DIR=kdevpg-install-path/share
to the
#cmake run if you installed it in a different directory than this plugin
#TODO: a cmake run is needed after changing one of the CMakeLists.txt, make will
#complain about the FindKDevelop-PG.cmake file not findable.
find_package(KDE4 REQUIRED)
exec_program(kde4-config ARGS --path data OUTPUT_VARIABLE _data_DIR)
file(TO_CMAKE_PATH ${_data_DIR} _data_DIR)
foreach(dir ${_data_DIR})
set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} ${dir}/share/cmake/modules)
endforeach(dir)
find_package(KDevPlatform REQUIRED)
find_package(KDevelop-PG)
find_package(Flex)
INCLUDE_DIRECTORIES(
${KDEVPLATFORM_INCLUDE_DIR}/language/interfaces
${KDEVPLATFORM_INCLUDE_DIR}/interfaces
${KDEVPLATFORM_INCLUDE_DIR}/language
${KDEVPLATFORM_INCLUDE_DIR}/language/backgroundparser
${KDE4_INCLUDES}
${KDE4_INCLUDE_DIR}/threadweaver
${CMAKE_CURRENT_BINARY_DIR}
parser
)
set(parser_STAT_SRCS
${CMAKE_CURRENT_SOURCE_DIR}/parser/decoder.cpp
${CMAKE_CURRENT_SOURCE_DIR}/parser/python_io.cpp
${CMAKE_CURRENT_SOURCE_DIR}/parser/pythondriver.cpp
)
set(parser_SRCS)
set(lexer_SRCS)
macro(GET_PARSER_SRCS _srcsList)
if(KDEVPG_FOUND AND FLEX_FOUND)
include_directories(${KDEVPG_INCLUDE_DIR})
add_custom_command(
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/python_ast.h
${CMAKE_CURRENT_BINARY_DIR}/python_parser.h
${CMAKE_CURRENT_BINARY_DIR}/python_parser.cpp
${CMAKE_CURRENT_BINARY_DIR}/python_visitor.h
${CMAKE_CURRENT_BINARY_DIR}/python_visitor.cpp
${CMAKE_CURRENT_BINARY_DIR}/python_default_visitor.h
${CMAKE_CURRENT_BINARY_DIR}/python_default_visitor.cpp
DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/parser/python.g
${CMAKE_CURRENT_SOURCE_DIR}/parser/python_lexer.h
COMMAND ${KDEVPG_EXECUTABLE}
ARGS--output=python
${CMAKE_CURRENT_SOURCE_DIR}/parser/python.g
WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
)
add_custom_target( debuginfo
${KDEVPG_EXECUTABLE} --terminals
${CMAKE_CURRENT_SOURCE_DIR}/parser/python.g terminals
COMMAND ${KDEVPG_EXECUTABLE} --symbols
${CMAKE_CURRENT_SOURCE_DIR}/parser/python.g symbols
COMMAND ${KDEVPG_EXECUTABLE} --rules
${CMAKE_CURRENT_SOURCE_DIR}/parser/python.g rules
2errors
WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
)
set( _srcsList
${CMAKE_CURRENT_BINARY_DIR}/python_parser.cpp
${CMAKE_CURRENT_BINARY_DIR}/python_visitor.cpp
${CMAKE_CURRENT_BINARY_DIR}/python_default_visitor.cpp)
add_custom_command(
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/python_lexer.cpp
DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/parser/python_lexer.ll
${CMAKE_CURRENT_SOURCE_DIR}/parser/python_lexer.h
${CMAKE_CURRENT_BINARY_DIR}/python_parser.h
COMMAND ${FLEX_EXECUTABLE}
ARGS-o${CMAKE_CURRENT_BINARY_DIR}/python_lexer.cpp
-d
${CMAKE_CURRENT_SOURCE_DIR}/parser/python_lexer.ll
WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
)
set(_srcsList ${_srcsList} ${CMAKE_CURRENT_BINARY_DIR}/python_lexer.cpp)
else(KDEVPG_FOUND AND FLEX_FOUND)
include_directories(${CMAKE_SOURCE_DIR}/parser/generated)
message(STATUS Assuming existence of generated parser files)
set(_srcsList
${CMAKE_CURRENT_SOURCE_DIR}/parser/generated/python_parser.cpp
${CMAKE_CURRENT_SOURCE_DIR}/parser/generated/python_visitor.cpp
${CMAKE_CURRENT_SOURCE_DIR}/parser/generated/python_default_visitor.cpp
)
message( STATUS Assuming existence of generated lexer files)
set(_srcsList ${_srcsList}
Re: playground/devtools/kdevelop4-extra-plugins/python/parser
On 10.07.07 11:20:46, Andreas Pakulat wrote:
On 09.07.07 23:22:23, Alexander Neundorf wrote:
On Monday 09 July 2007 14:22, Andreas Pakulat wrote:
python/parser/CMakeLists.txt with
add_executable(python-parser ${foo_SRCS} )
Then cmake will complain that it doesn't know how to create the files in
foo_SRCS for the python-parser target.
And always setting the foo_SRCS GENERATED in the subdirs is not really
usable either as they are only generated when you've got the generator
tool installed (which is not required). So I'd again need to have
if(FOO_FOUND) stuff everywhere.
Can you put the rules for generating the files in the directories where the
file are used, e.g. with some macros ?
Hmm, can you have a look at the attached file please? Calling the macro
doesn't execute the custom command and thus the files are not generated.
Nevermind, figured it myself :)
--
Never commit yourself! Let someone else commit you.
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: playground/devtools/kdevelop4-extra-plugins/python/parser
On Tuesday 10 July 2007 16:08, Andreas Pakulat wrote:
...
I think the macro I came up with causes a full rebuild of the project
using it when touching any of the CMakeLists.txt.
An example is playground/devtools/kdevelop4-extra-plugins/ruby
if I touch tests/CMakeLists.txt the whole project is rebuilt, the
generated and non-generated files are all recompiled.
The macro I use looks like this:
macro(GET_GENERATED_SRCS _srcsList)
if(KDEVPG_FOUND AND FLEX_FOUND)
include_directories(${KDEVPG_INCLUDE_DIR})
kdevpg_generate(_kdevpgList ruby DEBUG_VISITOR
${CMAKE_SOURCE_DIR}/parser/ruby.g
${CMAKE_SOURCE_DIR}/parser/ruby_lexer.h)
# Copy ruby_lexer.ll to the builddir, so that flex doesn't write
out # absolute paths in the generated file when we pass them as arguments.
# In short, I don't want stuff like
# '#line 2 /home/kde/build/.../ruby_lexer.cpp in SVN.
add_custom_command(
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/ruby_lexer.ll
MAIN_DEPENDENCY ${CMAKE_SOURCE_DIR}/parser/ruby_lexer.ll
COMMAND ${CMAKE_COMMAND} ARGS -E copy_if_different
${CMAKE_SOURCE_DIR}/parser/ruby_lexer.ll
${CMAKE_CURRENT_BINARY_DIR}/ruby_lexer.ll
)
# Add command to generate the lexer.
add_custom_command(
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/ruby_lexer.cpp
MAIN_DEPENDENCY ${CMAKE_CURRENT_BINARY_DIR}/ruby_lexer.ll
DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/ruby_parser.h
${CMAKE_SOURCE_DIR}/parser/ruby_lexer.h
COMMAND ${FLEX_EXECUTABLE}
ARGS-oruby_lexer.cpp
ruby_lexer.ll
WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
)
set(${_srcsList} ${_kdevpgList}
${CMAKE_CURRENT_BINARY_DIR}/ruby_lexer.cpp) else(KDEVPG_FOUND AND
FLEX_FOUND)
include_directories(${CMAKE_SOURCE_DIR}/parser/generated)
message(STATUS Assuming existence of generated parser files)
message( STATUS Assuming existence of generated lexer files)
set(${_srcsList}
${CMAKE_SOURCE_DIR}/parser/generated/ruby_parser.cpp
${CMAKE_SOURCE_DIR}/parser/generated/ruby_visitor.cpp
${CMAKE_SOURCE_DIR}/parser/generated/ruby_default_visitor.cpp
${CMAKE_SOURCE_DIR}/parser/generated/ruby_lexer.cpp )
endif(KDEVPG_FOUND AND FLEX_FOUND)
endmacro(GET_GENERATED_SRCS)
Ok, not sure what is causing this.
You should be able to merge the two add_custom_command()s into one as below:
macro(GET_GENERATED_SRCS _srcsList)
if(KDEVPG_FOUND AND FLEX_FOUND)
include_directories(${KDEVPG_INCLUDE_DIR})
kdevpg_generate(_kdevpgList ruby DEBUG_VISITOR
${CMAKE_SOURCE_DIR}/parser/ruby.g
${CMAKE_SOURCE_DIR}/parser/ruby_lexer.h)
# Add command to generate the lexer.
add_custom_command(
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/ruby_lexer.cpp
MAIN_DEPENDENCY ${CMAKE_CURRENT_BINARY_DIR}/ruby_lexer.ll
DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/ruby_parser.h
${CMAKE_SOURCE_DIR}/parser/ruby_lexer.h
COMMAND ${CMAKE_COMMAND} -E copy_if_different
${CMAKE_SOURCE_DIR}/parser/ruby_lexer.ll
${CMAKE_CURRENT_BINARY_DIR}/ruby_lexer.ll
COMMAND ${FLEX_EXECUTABLE} -o ruby_lexer.cpp ruby_lexer.ll
WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
)
set(${_srcsList}
${_kdevpgList} ${CMAKE_CURRENT_BINARY_DIR}/ruby_lexer.cpp)
else(KDEVPG_FOUND AND FLEX_FOUND)
include_directories(${CMAKE_SOURCE_DIR}/parser/generated)
message(STATUS Assuming existence of generated parser files)
message( STATUS Assuming existence of generated lexer files)
set(${_srcsList}
${CMAKE_SOURCE_DIR}/parser/generated/ruby_parser.cpp
${CMAKE_SOURCE_DIR}/parser/generated/ruby_visitor.cpp
${CMAKE_SOURCE_DIR}/parser/generated/ruby_default_visitor.cpp
${CMAKE_SOURCE_DIR}/parser/generated/ruby_lexer.cpp )
endif(KDEVPG_FOUND AND FLEX_FOUND)
endmacro(GET_GENERATED_SRCS)
This probably doesn't change it.
One way to debug this would be the following.
Build the buildtree.
Run cmake on it, you can simply run cmake build_dir
Then copy this buildtree to some other location so you can test against it
later.
Run cmake again on the original buildtree.
Find out the differences between the buildtree and the previous buildtree.
Then we'll see what has changed.
Alex
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: playground/devtools/kdevelop4-extra-plugins/python/parser
On Friday, 6. July 2007, Andreas Pakulat wrote: Thats not feasible, because some of the sources (though not all) may be generated (or may be not generated if the generator is missing) and thus I'd have to copy the generation code into each CMakeLists.txt that wants to use the sources. Ehm, parse error here. you only have to SET a variable and use that one in other places. Unless I'm missing something. Dirk ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: playground/devtools/kdevelop4-extra-plugins/python/parser
Andreas Pakulat wrote: Add -fPIC, that seems to be the only option to use a static lib in a plugin on 64Bit platforms No, the correct solution is to not use a static lib at all. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: playground/devtools/kdevelop4-extra-plugins/python/parser
On 05.07.07 21:09:23, Matt Rogers wrote: On Jul 5, 2007, at 6:01 PM, Andreas Pakulat wrote: SVN commit 684033 by apaku: Add -fPIC, that seems to be the only option to use a static lib in a plugin on 64Bit platforms CCing kde-buildsystem because I'm not sure this is the right thing to do. Making it a shared library is a problem because parts of the code is generated and the generator doesn't allow to add EXPORT macro's. The question is: Use -fPIC or build a shared lib that has visibility=default instead of hidden? CCMAIL:kde-buildsystem@kde.org Yes, this is wrong, IIRC. This needs to be a shared lib with its own export macro instead. Then somebody has to add an option to kdevelop-pg to tell it such a macro. Andreas -- Today is the tomorrow you worried about yesterday. ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: playground/devtools/kdevelop4-extra-plugins/python/parser
On Friday, 6. July 2007, Andreas Pakulat wrote: Add -fPIC, that seems to be the only option to use a static lib in a plugin on 64Bit platforms no, link the sources directly instead of adding a static library. Dirk ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: playground/devtools/kdevelop4-extra-plugins/python/parser
On 06.07.07 11:26:57, Dirk Mueller wrote: On Friday, 6. July 2007, Andreas Pakulat wrote: Add -fPIC, that seems to be the only option to use a static lib in a plugin on 64Bit platforms no, link the sources directly instead of adding a static library. Thats not feasible, because some of the sources (though not all) may be generated (or may be not generated if the generator is missing) and thus I'd have to copy the generation code into each CMakeLists.txt that wants to use the sources. Andreas -- The whole world is a tuxedo and you are a pair of brown shoes. -- George Gobel ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
playground/devtools/kdevelop4-extra-plugins/python/parser
SVN commit 684033 by apaku:
Add -fPIC, that seems to be the only option to use a static lib in a plugin on
64Bit platforms
CCing kde-buildsystem because I'm not sure this is the right thing to do.
Making it a shared library is a problem because parts of the code is generated
and the generator doesn't allow to add EXPORT macro's.
The question is: Use -fPIC or build a shared lib that has visibility=default
instead of hidden?
CCMAIL:kde-buildsystem@kde.org
M +3 -0 CMakeLists.txt
---
trunk/playground/devtools/kdevelop4-extra-plugins/python/parser/CMakeLists.txt
#684032:684033
@@ -1,6 +1,9 @@
add_subdirectory(tests)
+## Is this really supported on all architectures??
+add_definitions(-fPIC)
+
include_directories(${CMAKE_CURRENT_SOURCE_DIR})
include_directories(${CMAKE_CURRENT_BINARY_DIR})
include_directories(${QT_INCLUDES})
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: playground/devtools/kdevelop4-extra-plugins/python/parser
On Jul 5, 2007, at 6:01 PM, Andreas Pakulat wrote: SVN commit 684033 by apaku: Add -fPIC, that seems to be the only option to use a static lib in a plugin on 64Bit platforms CCing kde-buildsystem because I'm not sure this is the right thing to do. Making it a shared library is a problem because parts of the code is generated and the generator doesn't allow to add EXPORT macro's. The question is: Use -fPIC or build a shared lib that has visibility=default instead of hidden? CCMAIL:kde-buildsystem@kde.org Yes, this is wrong, IIRC. This needs to be a shared lib with its own export macro instead. -- Matt ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
