Re: [cmake-developers] ReactOS: Important filed bug reports went to backlog en masse
Just idly, I wonder how practical it would be to automatically close bugs older than XXX time that haven't been touched or assigned. If nothing else it'd generate a notification to the submitter of the bug that either the bug was over looked or not considered important and deserves some discussion if they want it fixed. I've read a few articles online about doing this sort of thing to clear the 'fog' of irrelevant issues that clogs up bug trackers, esp. public ones. ~ Doug. On Sun, Aug 12, 2012 at 8:10 PM, David Cole david.c...@kitware.com wrote: I certainly did not mean to offend anyone with my en masse move of issues to 'backlog' -- thanks for speaking up. I would like to make sure that you guys can continue to use CMake for ReactOS. I've got to run right now, but I will reply again tomorrow when I have some more time. Do you have time for a quick phone call or Google+ hangout this week sometime, so I can understand better what your issues are? (And why nobody adopted them when they appeared on the mailing list in the form of your bug reports...) Thanks, David Cole On Sat, Aug 11, 2012 at 9:42 PM, Amine Khaldi amine.kha...@reactos.org wrote: Hello folks, I would like to mention that many (if not all) the bugs coming from us (ReactOS) got into backlog. We're an operating system project, we try to file bug report only for issues that block us, so we do not tend to file trivial bugs. It would be great if the CMake folks tried to pay the attention that our issues deserve.. after all, we started using CMake because we read many positive reviews about the excellent support. Unfortunately, we're not able to use the VS generators due to the lack of support for ASM preprocessed files. We're not able to pass flags to C/C++ source files without affecting the rc (resource) files. We're forced to do many ugly workarounds for the latter, and we found no solution for the former, and these are just examples. All these mentioned issues got into the backlog, so basically we're left off, without any help to get them solved. I'm writing this hopefully as a call to the CMake folks/community to address our issues, that we've been waiting release after release to get them fixed, only to find out that they ended up in backlog now. I'm writing this in the hopes of finding a CMake developer who has the bandwidth to take it on, and ferry a fix through to our 'next' branch for dashboard testing. Regards, Amine. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] lua bindings?
Sorry, lots of talk. Tangibly I imagine something like this:
local helper = cmake:context()
helper.set_build_dir(helper)
helper.configure(-DBUILD_TESTS=ON)
helper:file(GLOB_RECURSE, SOURCES, ${CMAKE_CURRENT_SOURCE_DIR}/*.c)
helper:add_library(help, SHARED, ${SOURCES})
helper:get_property(HELP_LIB, TARGET, help, PROPERTY, LOCATION)
helper:configure_file(${PROJECT_SOURCE_DIR}/config.in,
${PROJECT_BINARY_DIR}/config)
helper.generate()
helper.compile()
fp = io.open(helper/config, r)
help = fp:read(*all)
fp:close()
local factory,err = package.loadlib(help,'luaopen_help')
if not fn then print(err)
else
helper = factory()
end
app = cmake:context()
app.set_build_dir(app)
helper.set_automake_path(lib/tools/openssl-1.0.1c)
helper.automake(app)
app.generate()
app.compile()
Note that this is not a dynamic invokation of cmake; you cannot go:
files = helper.get_value(SOURCES); foreach i, k in pairs(files) ...
or similar because this is a cached script builder, not a dynamic
script evaluator.
This sucks in some ways, but vastly lowers the complexity of implementing it.
~
Doug.
On Sat, Aug 4, 2012 at 6:10 AM, Bill Hoffman bill.hoff...@kitware.com wrote:
On 8/3/2012 5:30 PM, Óscar Fuentes wrote:
Brad King brad.k...@kitware.com writes:
[snip]
As for your first option, a zero-impact wrapper, what do you
envision would be the benefits?
[I'm not the OP]
Something I sorely miss on CMake is a way to express algorithms in a
clear way and to process large amounts of data efficiently.
For an example that could benefit from a cleaner and more expressive
language, see function explicit_map_components_to_libraries in
http://www.llvm.org/viewvc/llvm-project/llvm/trunk/cmake/modules/LLVM-Config.cmake?revision=145355view=markup
On the same project, there was several perl scripts that I'll like to
implement on CMake (and hence drop the Perl requirement.) Those scripts
walked through all defined and referenced symbols on all libraries on
the project for creating library dependencies. On another instance, a
similar taks would be performed on Visual C++ for creating .def files
and dll's. On both cases I stumbled on the language's lack of
expresiveness, minimal support for data structures and on an apparent
O(n^2) time complexity on some list operations (including the append
operation, IIRC)
So, we have talked about this at Kitware some recently and came up with a
gradual approach that should work.
1. Add lua to cmake as a command. Something like cmake -E tar, but cmake -E
lua. This would mean that lua would always be something you could count on
having with cmake.
2. Add a simple integration into the cmake language that lets you evaluate
lua inside a cmake file. Something like eval_lua(...).
3. If 1 and 2 go well, investigate binding the cmake commands into lua.
(LuaCMake)
With this approach there would be benefit to the whole cmake community from
Lua. You would not have to convert your project to LuaCMake (3) to take
advantage of more expressive language. You could just eval some lua
statements in an existing large cmake project. I would not want to fork
cmake into lua cmake and cmake cmake, but this path forward would avoid
that.
All that said, we do not at the moment have funding for such a project at
Kitware.
-Bill
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] Fwd: lua bindings?
Woops; wrong reply button. :P -- Forwarded message -- From: Doug douglas.lin...@gmail.com Date: Sat, Aug 4, 2012 at 8:07 AM Subject: Re: [cmake-developers] lua bindings? To: Brad King brad.k...@kitware.com I've found lately that I am using increasingly complex scripts to convert existing automake projects (notably freeglut, openssl 1.0.1 and freetype) to cmake. These projects dont support cmake directly, and dont really have any intention of doing so, and the only way to cleanly support them in a way that doesnt break from release to release (or at least has minimal impact) is to load and process the automake files. I realize this is terrible, but practically speaking it works relatively well. However, ive never really been very happy with cmake functions and macros, and writing a script to do these tasks is annoying in cmake itself. I'm presently using a c boost strap, which compiles into an application that runs, parses files, and generates a cmakelists.txt. Then running cmake again on the result. ...but I'm not really happy with it. So i started to experiment with a lua runner, which was executed by execute_process() followed by add_subdirectory() and that led me to wondering about complex build scripts and lua integration. The only real benefit of a lua wrapper would be it has zero impact on the code base, and does not depend on the code itself; a (for example) 2.8.x wrapper could continue to function even long after 2.8 is no longer the most recent so long as no backwards incompatible language syntax changes were made. Sharply in contrast, a 2.8 fork with lua bindings would become obsolete almost immediately and require constant remerging to remain functional. Even if i supported it for a month or year, eventually id move on and the project would get abandoned unless it was officially adopted; and that seems unlikely. Tangibly the benefits of a script in lua this way for me would be: - modularised code base support, real language constructs Ie. better than cmakes include and add directives with search paths, all the normal lua stuff. - complex build augmentation via dynamic library loading Making cmake into the kitchen sink aka python with a million of its dependencies isnt a great idea. However, if you do need complex build rules, you could have an external module (automake portability tools, certificate signing, reading zipfiles) that was invoked as a subproject and built by cmake then loaded as a dynamic lua extension and then the build could continue. This 'build binaries, then continue build scripts' approach is, as far as i can tell, simply not possible from cmake at the moment; execute process is as close as you can get. That said, its not without challenges. Particularly build progress (90%...but wait that was only the first cmake call...) and cmake configuration ccmake, etc. are something i havent figured out yet. ~ Doug. On Aug 4, 2012 4:55 AM, Brad King brad.k...@kitware.com wrote: On 08/03/2012 04:33 PM, Eric Wing wrote: Yes, there was a big long thread on the CMake lists back in 2008-ish The main two threads started here: http://www.cmake.org/pipermail/cmake/2007-November/017347.html http://www.cmake.org/pipermail/cmake/2007-November/017971.html Ken's experiment only scratched the surface. There are many very hard problems with trying to replace the CMake language with Lua directly in CMake itself. For historical reasons a large part of the build system generators are tied to the CMake language implementation. The language has some unique semantic properties which cannot be reproduced cleanly in Lua, and we probably wouldn't want them in a new language anyway. Direct replacement is not feasible. Perhaps some major internal redesign and refactoring could possibly split the generation part off into a private SDK shared by the existing language and some new language, but it would be a huge effort. As for your first option, a zero-impact wrapper, what do you envision would be the benefits? -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] lua bindings?
I'm quite curious about the possibility of writing a lua binding for cmake. There are two possible ways to go: 1) Create a set of discrete lua bindings which actually invoke cmake itself. 2) Integrate lua into cmake itself. Before I go and do anything, has any effort been made to do either of these? From the lua mailing list I get the impression that some discussion of (2) has been done before, and broadly speaking, no one is really interested in re-writing cmake to support lua scripts as first class citizens. However, (1) interests me, because it'd be reasonably trivial to implement a lua binding of commands like: cmake:execute_process cmake:add_library cmake:target_link_library That cached the requests internally and actually generated a cmakelists.txt from it. There are some difficulties with this approach, for example, some actions require an immediate response that can't be cached; eg. file(GLOB) - filtering that list to invoke add_library()... but I think it wouldn't be impossible to generate temporary 'working' cmake files and invoke cmake on them directly, read the response and pipe it back into the lua script. This would be effectively a zero-impact wrapper around cmake, and make supporting more complex programming constructs (poor support for closures, hashes and lists specifically being my pet dislike with the cmake language). So, like I said, before I start down the road of messing around with this, has anyone got any thoughts about it, past experience and suggestions? Cheers, Doug. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
