Re: [cmake-developers] conditionals in generator expressions
On 08/30/2012 11:55 AM, Stephen Kelly wrote: > From earlier: >> One way to distinguish expressions with free-form arguments from >> those without is whether there is a ':' or whitespace after the >> expression name. > > This isn't very clear to me. Should ':' be part of the syntax which is > always needed? Or only needed in disambiguation cases? I'm not in favor of > syntax which is only used in a small subset of expressions only for > disambiguation. > > If ':' must appear after the expression name sometimes, then it should have > to be there all the time. It is a way to disambiguate for compatibility with the existing expressions while still allowing them to be used with the new syntax if we want. IMO $ is more readable than $ but we could support both and let the user decide. We could simply say that the "$" form is equivalent to "$" treating all the content after ":" as one argument. > You mean an evolution of this? > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/3615/focus=3756 Yes. > So if we reintroduce IF, we'll en up with something like this: > > 1) "$ /rel/ease /de/bug>" > > 2) "$ > Qt5::WinMain>" > > 3) "$ "WIN32_EXECUTABLE> > Qt5::WinMain>" > > 4) "$ WIN32_EXECUTABLE> > Qt5::WinMain>" > > 5) "$ $ > > $ EXECUTABLE> > > Qt5::WinMain>" > > ? > > I guess 3 won't work, but 4 would be used instead? Yes. > I think I can adapt the parser to that. Before jumping into the code please try to construct a formal grammar for discussion. That will split review of the code from review of the grammar. > That also means discarding the $<0:...> and $<1:...> basis for all of it I'm fine with that since it hasn't been released yet anyway. They are not mutually exclusive though. My above definition of the ":" behavior still allows it. In the case of AND/OR/NOT the single argument would be parsed inside their evaluation to extract the "0" "1" and "," pieces. -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] [CMake 0013499]: CMake AUTOMOC creates empty .moc files.
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13499
==
Reported By:Stephen Kelly
Assigned To:Alex Neundorf
==
Project:CMake
Issue ID: 13499
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: assigned
==
Date Submitted: 2012-08-30 12:55 EDT
Last Modified: 2012-08-30 12:55 EDT
==
Summary:CMake AUTOMOC creates empty .moc files.
Description:
With a simple hello world application automoc is generating empty .moc files:
stephen@hal:~/dev/src/playground/cmake/native{master}$ make
makeobj[0]: Entering directory `/home/stephen/dev/src/playground/cmake/native'
Scanning dependencies of target helloworld_automoc
[ 25%] Automoc for target helloworld
Generating mainwindow.moc
/home/stephen/dev/src/playground/cmake/mainwindow.cpp:8: Note: No relevant
classes found. No output generated.
Generating moc_mainwindow.cpp
[ 25%] Built target helloworld_automoc
Scanning dependencies of target helloworld
[ 50%] [ 75%] [100%] Building CXX object CMakeFiles/helloworld.dir/main.cpp.o
Building CXX object CMakeFiles/helloworld.dir/mainwindow.cpp.o
Building CXX object CMakeFiles/helloworld.dir/helloworld_automoc.cpp.o
Linking CXX executable helloworld
[100%] Built target helloworld
makeobj[0]: Leaving directory `/home/stephen/dev/src/playground/cmake/native'
stephen@hal:~/dev/src/playground/cmake/native{master}$ l
CMakeCache.txt CMakeFiles/ cmake_install.cmake helloworld*
helloworld_automoc.cpp mainwindow.moc Makefile moc_mainwindow.cpp
stephen@hal:~/dev/src/playground/cmake/native{master}$ wc mainwindow.moc
moc_mainwindow.cpp
000 mainwindow.moc
81 242 2351 moc_mainwindow.cpp
81 242 2351 total
stephen@hal:~/dev/src/playground/cmake/native{master}$ cat ../main.cpp
#include
#include "mainwindow.h"
int main(int argc, char **argv)
{
QApplication app(argc, argv);
MainWindow mw;
mw.show();
return app.exec();
}
stephen@hal:~/dev/src/playground/cmake/native{master}$ cat ../mainwindow.cpp
#include "mainwindow.h"
MainWindow::MainWindow(QWidget *parent)
{
}
#include "mainwindow.moc"
stephen@hal:~/dev/src/playground/cmake/native{master}$ cat ../mainwindow.h
#include
class MainWindow : public QWidget
{
Q_OBJECT
public:
MainWindow(QWidget *parent = 0);
};
stephen@hal:~/dev/src/playground/cmake/native{master}$ cat ../CMakeLists.txt
cmake_minimum_required(VERSION 2.8)
set(CMAKE_INCLUDE_CURRENT_DIR ON)
set(CMAKE_AUTOMOC ON)
find_package(Qt4 REQUIRED)
include_directories(${QT_INCLUDES})
add_executable(helloworld
main.cpp
mainwindow.cpp
)
target_link_libraries(helloworld ${QT_QTGUI_LIBRARIES} ${QT_QTCORE_LIBRARIES})
==
Issue History
Date ModifiedUsername FieldChange
==
2012-08-30 12:55 Stephen Kelly New Issue
2012-08-30 12:55 Stephen Kelly Status new => assigned
2012-08-30 12:55 Stephen Kelly Assigned To => Alex Neundorf
==
--
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] conditionals in generator expressions
Brad King wrote: > The entire expression must still be quoted and have its internal syntax > escaped through the CMake language. We could use single quotes instead: > > set_property(TARGET foolib >[APPEND] PROPERTY INCLUDE_DIRECTORIES >"$<$ '/bar bat/bag'>" >) > > for quoting inside generator expressions. Yes. >> set_target_properties(foolib >> PROPERTIES COMPILE_OPTIONS >> "$<$:-Wl$no-undefined>" >> ) > > That is a good example of a reason not to use comma for separation. Yes. It makes it a non-starter IMO. >> Looking at my keyboard, how about '?' '|' '\'' '#' or '*'? > Yes, I think comma was most readable, but it's a non-starter. > I don't think any of them is particularly readable. Using whitespace > and quoting will allow free-form arrangement for readability. >From earlier: > One way to distinguish expressions with free-form arguments from > those without is whether there is a ':' or whitespace after the > expression name. This isn't very clear to me. Should ':' be part of the syntax which is always needed? Or only needed in disambiguation cases? I'm not in favor of syntax which is only used in a small subset of expressions only for disambiguation. If ':' must appear after the expression name sometimes, then it should have to be there all the time. > If we > define the rules carefully so that $<> protects internal quotes then > we can go back to the if/then/else approach I previously discarded: > > "$" > You mean an evolution of this? http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/3615/focus=3756 So if we reintroduce IF, we'll en up with something like this: 1) "$ /rel/ease /de/bug>" 2) "$ > Qt5::WinMain>" 3) "$ > Qt5::WinMain>" 4) "$ > Qt5::WinMain>" 5) "$ > $ EXECUTABLE> > Qt5::WinMain>" ? I guess 3 won't work, but 4 would be used instead? I think I can adapt the parser to that. That also means discarding the $<0:...> and $<1:...> basis for all of it, and possibly deprecating the use of ':' as a delimiter for the existing expressions like TARGET_FILE? I can probably do that in the parser too. Thanks, Steve. -- 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] [CMake 0013498]: CMake does not fully support Visual Studio 11 WinRT project type
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=13498
==
Reported By:Andrzej
Assigned To:
==
Project:CMake
Issue ID: 13498
Category: CMake
Reproducibility:always
Severity: feature
Priority: normal
Status: new
==
Date Submitted: 2012-08-30 11:50 EDT
Last Modified: 2012-08-30 11:50 EDT
==
Summary:CMake does not fully support Visual Studio 11 WinRT
project type
Description:
CMake currently does not fully support setting project type as needed to develop
WinRT applications for Windows 8 with the Visual Studio 11 generator.
A lot of work was done here : http://www.cmake.org/Bug/view.php?id=12930
But that is not enought.
VS_WINRT_EXTENSIONS add true tag to
tag witch have specific "Condition".
Example output :
Application
v110
true
Because of that we are able to compile windows runtime code and generate .exe
code.
But the next step after compilation is to deploy app and try to debug. We need
true tag to obtain that
feature on. That will be in tag.
Example :
{93441f5d-57bf-4021-a2e3-973fac0ac3c4}
Direct3DApp1
en-US
11.0
true
(source from Visual Studio Professional 2012 Direct3DApp sample )
Generaly using instead of will
make whole process more easly. in "Globals" label
override all "Configuration" labels and make it possible to deploy and debug
WinRT app. Additionally make "Windows Store App
Support" to grey and hardcode "Yes" statement.
Pure Visual Studio 2012 WinRT sample app use only tag.
==
Issue History
Date ModifiedUsername FieldChange
==
2012-08-30 11:50 AndrzejNew Issue
==
--
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] Mantis limitation
Thanks for the pointer to the Form Recovery browser extension. That will help, if I can remember to install it again whenever I switch computers... :-) In the meantime, our IT guys have said they've "doubled gc_maxlifetime which may make it happen less frequently -- seems to be the only option so far." If anybody comes across information about how to avoid this problem entirely, please do pass it along here. Thanks, David Cole On Mon, Aug 27, 2012 at 10:33 AM, Nicolas Desprès wrote: > I personally use the "Lazareus: Form Recovery" web browser extension for > this purpose. I have never lost any typed message since it is enabled. > Available for Chrome and Firefox. > > > On Mon, Aug 27, 2012 at 4:24 PM, David Cole wrote: >> >> That would be awesome. I HATE it when that happens to me in Mantis (at >> least once every few months, and it's always very irritating...) >> >> I'll ask our sysadmin guys, don't know if there's a Mantis update we >> could take or something but I'll ask. >> >> >> On Sun, Aug 26, 2012 at 2:44 AM, Eric Noulard >> wrote: >> > Hi Guys, >> > >> > Is there anything that can be done with the Mantis Installation that >> > prevent loosing >> > a comment when session expired? >> > >> > I got caught several time and it looks like I'm not alone >> > on this: >> > http://public.kitware.com/Bug/view.php?id=13490#c30764 >> > >> > Now when I type a long comment I do it in a text editor and >> > copy/paste it to mantis form in order to be sure not to loose >> > it. >> > >> > May be it can fixed on Mantis side? >> > -- >> > Erk >> > Le gouvernement représentatif n'est pas la démocratie -- >> > http://www.le-message.org >> > -- >> > >> > 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 > > > > > -- > Nicolas Desprès > -- 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] [CMake 0013497]: CMAKE_SKIP_INSTALL_RPATH removes RPATH but leaves empty RUNPATH.
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13497 == Reported By:marled Assigned To: == Project:CMake Issue ID: 13497 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2012-08-30 10:34 EDT Last Modified: 2012-08-30 10:34 EDT == Summary:CMAKE_SKIP_INSTALL_RPATH removes RPATH but leaves empty RUNPATH. Description: Hello, I used the downloadable binary version of cmake for this test. If I do not specify options for RPATH specific features, then the behaviour is the same - this is probably the default anyway. My first question is that if this behaviour (= empty RUNPATH) is intendend? Since I assume not, both fields, RPATH and RUNPATH, should always have the same contents or should both not exist at all. I could use CMAKE_BUILD_WITH_INSTALL_RPATH or CMAKE_SKIP_BUILD_RPATH which works around the problem, but then of course I would not be able to run programs from the build directory. Thank you for your answer, Martin Lederhilger Steps to Reproduce: Please see the test case in the attached tar.gz-file. #CONFIGURATION, BUILDING AND INSTALLING: frosch3:/home/lederhi/rpath/build $ cmake -DCMAKE_INSTALL_PREFIX=`pwd`/../install .. -- The C compiler identification is GNU 4.5.0 -- The CXX compiler identification is GNU 4.5.0 -- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Configuring done -- Generating done -- Build files have been written to: /home/lederhi/rpath/build frosch3:/home/lederhi/rpath/build $ make install Scanning dependencies of target a [ 33%] Building C object liba/CMakeFiles/a.dir/a.c.o Linking C shared library liba.so [ 33%] Built target a Scanning dependencies of target b [ 66%] Building C object libb/CMakeFiles/b.dir/b.c.o Linking C shared library libb.so [ 66%] Built target b Scanning dependencies of target prg [100%] Building C object CMakeFiles/prg.dir/prg.c.o Linking C executable prg [100%] Built target prg Install the project... -- Install configuration: "" -- Installing: /home/lederhi/rpath/install/bin/prg -- Removed runtime path from "/home/lederhi/rpath/install/bin/prg" -- Installing: /home/lederhi/rpath/install/liba/liba.so -- Installing: /home/lederhi/rpath/install/libb/libb.so -- Removed runtime path from "/home/lederhi/rpath/install/libb/libb.so" #IN THE BUILD DIRECTORY frosch3:/home/lederhi/rpath/build $ readelf -d prg liba/liba.so libb/libb.so File: prg Dynamic section at offset 0xf08 contains 24 entries: TagType Name/Value 0x0001 (NEEDED) Shared library: [libb.so] 0x0001 (NEEDED) Shared library: [libc.so.6] 0x000f (RPATH) Library rpath: [/home/lederhi/rpath/build/libb:/home/lederhi/rpath/build/liba:] 0x001d (RUNPATH)Library runpath: [/home/lederhi/rpath/build/libb:/home/lederhi/rpath/build/liba:] 0x000c (INIT) 0x804852c 0x000d (FINI) 0x804871c 0x0004 (HASH) 0x80481c4 0x6ef5 (GNU_HASH) 0x8048258 0x0005 (STRTAB) 0x80483d8 0x0006 (SYMTAB) 0x80482b8 0x000a (STRSZ) 238 (bytes) 0x000b (SYMENT) 16 (bytes) 0x0015 (DEBUG) 0x0 0x0003 (PLTGOT) 0x8049ff4 0x0002 (PLTRELSZ) 24 (bytes) 0x0014 (PLTREL) REL 0x0017 (JMPREL) 0x8048514 0x0011 (REL)0x804850c 0x0012 (RELSZ) 8 (bytes) 0x0013 (RELENT) 8 (bytes) 0x6ffe (VERNEED)0x80484ec 0x6fff (VERNEEDNUM) 1 0x6ff0 (VERSYM) 0x80484c6 0x (NULL) 0x0 File: liba/liba.so Dynamic section at offset 0xf18 contains 22 entries: TagType Name/Value 0x0001 (NEEDED) Shared library: [libc.so.6] 0x000e (SONAME)
Re: [cmake-developers] conditionals in generator expressions
On 08/30/2012 04:33 AM, Stephen Kelly wrote: > Other examples: > > $ > > $ > > Which looks like a fairly 'normal' escaping scheme from a c++ point of view. Yes. > because that set_target_properties signature can only take one argument > (there are other bug reports about this I think, but I don't recall if it's > changable). It's not changeable because the command takes alternate prop/value pairs: prop1 value1 prop2 value2 ... so each value must be fully quoted. That's one reason I created the general set_property command. As you point out it does not help in this situation: > set_property(TARGET foolib > [APPEND] PROPERTY INCLUDE_DIRECTORIES > $<$ "/bar bat/bag"> > ) > > it will create a list of strings. So the const char *input to the generator > expression will contain a ';' separated list of strings. The entire expression must still be quoted and have its internal syntax escaped through the CMake language. We could use single quotes instead: set_property(TARGET foolib [APPEND] PROPERTY INCLUDE_DIRECTORIES "$<$ '/bar bat/bag'>" ) for quoting inside generator expressions. > So the options are either: > > 1) Require the use of $ or $ inside generator expressions > 2) Introduce proper quoting rules. I don't think the current proposal for > that is readable enough to be beneficial, but with a different > parsing/quoting scheme not based on whitespace and "\"", it might be > workable. I don't like either option. > set_target_properties(foolib > PROPERTIES COMPILE_OPTIONS > "$<$:-Wl$no-undefined>" > ) That is a good example of a reason not to use comma for separation. > Colon is not an option because it makes the language more confusing, and > would require a $, which would need to be broadly used to escape > 'Qt5::Core' etc. > > Looking at my keyboard, how about '?' '|' '\'' '#' or '*'? I don't think any of them is particularly readable. Using whitespace and quoting will allow free-form arrangement for readability. If we define the rules carefully so that $<> protects internal quotes then we can go back to the if/then/else approach I previously discarded: "$" -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
Re: [cmake-developers] what happened to cmake users forum?
Skippy VonDrake wrote: > I remember belonging to a mailing list meant for general questions > from cmake users. > Where does on go no when the have a problem/question just using cmake? > This site: http://public.kitware.com/mailman/listinfo/dart > just lists "cmake-developers" and "cmake-commits". > Or does this list include user questions? > From looking at the archives it looks like its meant for developers > working on enhancing/fixing cmake. Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake i.e. cm...@cmake.org Eike -- signature.asc Description: This is a digitally signed message part. -- 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] FindFLEX version extraction failure
On 08/30/2012 09:40 AM, Rolf Eike Beer wrote: > Let's see if it works: > > af06482 FindFLEX: fix version extraction on Apple Great, thanks for the quick reply. -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
Re: [cmake-developers] what happened to cmake users forum?
On 08/30/2012 03:44 PM, Skippy VonDrake wrote: > I remember belonging to a mailing list meant for general questions > from cmake users. > Where does on go no when the have a problem/question just using cmake? > This site: http://public.kitware.com/mailman/listinfo/dart > just lists "cmake-developers" and "cmake-commits". > Or does this list include user questions? > From looking at the archives it looks like its meant for developers > working on enhancing/fixing cmake. > Here: http://public.kitware.com/mailman/listinfo/cmake HTH Michael -- 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] what happened to cmake users forum?
I remember belonging to a mailing list meant for general questions from cmake users. Where does on go no when the have a problem/question just using cmake? This site: http://public.kitware.com/mailman/listinfo/dart just lists "cmake-developers" and "cmake-commits". Or does this list include user questions? >From looking at the archives it looks like its meant for developers working on enhancing/fixing cmake. -- 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] FindFLEX version extraction failure
Brad King wrote: > Hi Eike, > > Please take a look at this failure: > > http://open.cdash.org/testDetails.php?test=157846638&build=2539416 > > -- FLEX_VERSION='flex 2.5.35 Apple(flex-31)' > CMake Error at CMakeLists.txt:53 (message): >unexpected: FLEX_VERSION does not begin with a decimal digit Let's see if it works: af06482 FindFLEX: fix version extraction on Apple Eike -- signature.asc Description: This is a digitally signed message part. -- 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] FindFLEX version extraction failure
Hi Eike, Please take a look at this failure: http://open.cdash.org/testDetails.php?test=157846638&build=2539416 -- FLEX_VERSION='flex 2.5.35 Apple(flex-31)' CMake Error at CMakeLists.txt:53 (message): unexpected: FLEX_VERSION does not begin with a decimal digit Thanks, -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
Re: [cmake-developers] New find module: FindGLEW.cmake
Benjamin Eikel wrote: > Am Donnerstag, 30. August 2012 um 13:00:48 schrieb Rolf Eike Beer: > > Alexander Neundorf wrote: > > > On Wednesday 29 August 2012, Benjamin Eikel wrote: > > > > Dear CMake developers, > > > > > > > > I have written a find module for the OpenGL Extension Wrangler (GLEW) > > > > [1] library (see attachment). I tried to follow all the instructions > > > > that I have found. I am willing to maintain that module. > > > > Unfortunately, the header file "glew.h" does not contain any version > > > > information. I could > > > > > > Cool :-) > > > From looking a bit around on the web, it seems other alternative names > > > for the glew library are "glew" and "glew32s" > > > Maybe you can add those two names to the find_library() call ? > > > > > > > extract version information using PkgConfig, but I have in mind that > > > > using PkgConfig is discouraged. I am looking forward to your feedback. > > > > > > If possible, it'd be nice to do that without pkg-config, that's right. > > > glew.h on my system contains several version-related macros, isn't any > > > of > > > these usable ? > > > > Why? My guess would be to check whatever works, i.e. test pkg-config first > > and if that doesn't give anything suitable then do the normal scanning. > > Cheking pkg-config first is possible. But that would mean that the result of > the find module depends on the availability of pkg-config (a version is > reported if and only if pkg-config is available). Is that desirable? The other possibility would be that the version is never available, which I think is worse. > > Or did you mean "do not _require_ pkg-config"? > > Because pkg-config is not available on all platforms, it is unwise to > require it. No question. Eike -- signature.asc Description: This is a digitally signed message part. -- 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] New find module: FindGLEW.cmake
Am Donnerstag, 30. August 2012 um 13:00:48 schrieb Rolf Eike Beer: > Alexander Neundorf wrote: > > On Wednesday 29 August 2012, Benjamin Eikel wrote: > > > Dear CMake developers, > > > > > > I have written a find module for the OpenGL Extension Wrangler (GLEW) > > > [1] library (see attachment). I tried to follow all the instructions > > > that I have found. I am willing to maintain that module. > > > Unfortunately, the header file "glew.h" does not contain any version > > > information. I could > > > > Cool :-) > > From looking a bit around on the web, it seems other alternative names > > for the glew library are "glew" and "glew32s" > > Maybe you can add those two names to the find_library() call ? > > > > > extract version information using PkgConfig, but I have in mind that > > > using PkgConfig is discouraged. I am looking forward to your feedback. > > > > If possible, it'd be nice to do that without pkg-config, that's right. > > glew.h on my system contains several version-related macros, isn't any of > > these usable ? > > Why? My guess would be to check whatever works, i.e. test pkg-config first > and if that doesn't give anything suitable then do the normal scanning. Cheking pkg-config first is possible. But that would mean that the result of the find module depends on the availability of pkg-config (a version is reported if and only if pkg-config is available). Is that desirable? > > Or did you mean "do not _require_ pkg-config"? Because pkg-config is not available on all platforms, it is unwise to require it. > > Eike > -- -- 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] New find module: FindGLEW.cmake
Alexander Neundorf wrote: > On Wednesday 29 August 2012, Benjamin Eikel wrote: > > Dear CMake developers, > > > > I have written a find module for the OpenGL Extension Wrangler (GLEW) [1] > > library (see attachment). I tried to follow all the instructions that I > > have found. I am willing to maintain that module. Unfortunately, the > > header file "glew.h" does not contain any version information. I could > > Cool :-) > From looking a bit around on the web, it seems other alternative names for > the glew library are "glew" and "glew32s" > Maybe you can add those two names to the find_library() call ? > > > extract version information using PkgConfig, but I have in mind that using > > PkgConfig is discouraged. I am looking forward to your feedback. > > If possible, it'd be nice to do that without pkg-config, that's right. > glew.h on my system contains several version-related macros, isn't any of > these usable ? Why? My guess would be to check whatever works, i.e. test pkg-config first and if that doesn't give anything suitable then do the normal scanning. Or did you mean "do not _require_ pkg-config"? Eike -- signature.asc Description: This is a digitally signed message part. -- 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] conditionals in generator expressions
Brad King wrote: > On 08/29/2012 09:25 AM, Brad King wrote: >>> I've pushed a generator-expression-refactor branch to my clone. It needs >>> some clean-up, de-duplication etc, but I'm looking for feedback on the >>> approach. >>> >>> In my branch, all parameters must be separated by ','. All commas and >>> colons must appear literally in the expression. This makes escaping >>> not-needed, and multiple-parameter-separators consistent accross all >>> generators. >> >> Great. I'll take a look when I get a chance. > > That looks like a good start. Pre-parsing the entire expression tree > is the right approach. > > While quoting/escaping expanded values is not needed we still need > it for the input, like STREQUAL comparing to "," for example. The first solution that comes to mind within the current implementation is a or similar. Reading on... > > When we first designed generator expressions it was just for the > basic "$"-type expressions. The format for target > names was restricted so we didn't need to think about handling > arbitrary content. The $<0:...> and $<1:...> expressions can > have arbitrary content other than ">" but they always have exactly > one "parameter" so there is no real parsing involved. > > When I mentioned the "$" expression it was just as an example > of what the current approach can do (a better name might be ANGLE-R). > However, now that you're writing a real lexer/parser we need to think > about how this new mini-language will work syntactically. There should > be no need for $ if we have proper quoting rules. Consider > bash syntax like > > echo $(echo 'nested command with )') > > where the quoting protects the close-parenthesis inside $(...) syntax. > In order to allow more readable inputs we could consider allowing > arbitrary whitespace to separate arguments, as in: > > $" > "EXECUTABLE"> > > just like the CMake language itself. If quoting is parsed as part > of the syntax then it can be used for '>' too e.g. > > $"> > > where quoting protects argument contents as in bash. Other examples: $ $ Which looks like a fairly 'normal' escaping scheme from a c++ point of view. However, the problem is that these generator expressions are in strings already. Which means we'll have this: set_target_properties(foolib PROPERTIES INCLUDE_DIRECTORIES "$<$ \"/bar bat/bag\">" ) because that set_target_properties signature can only take one argument (there are other bug reports about this I think, but I don't recall if it's changable). I don't think it's very readable. In my branch it would be this instead: set_target_properties(foolib PROPERTIES INCLUDE_DIRECTORIES "$<$>:/bar bat/bag>" ) which is also not perfect, but is better. In the case of: set_property(TARGET foolib [APPEND] PROPERTY INCLUDE_DIRECTORIES $<$ "/bar bat/bag"> ) it will create a list of strings. So the const char *input to the generator expression will contain a ';' separated list of strings. > > One way to distinguish expressions with free-form arguments from > those without is whether there is a ':' or whitespace after the > expression name. I don't think that benefits readability. So the options are either: 1) Require the use of $ or $ inside generator expressions 2) Introduce proper quoting rules. I don't think the current proposal for that is readable enough to be beneficial, but with a different parsing/quoting scheme not based on whitespace and "\"", it might be workable. I think that (1) is cheap and worth it. One unfortunate place where it doesn't fit and where $ would have to be broadly used would be this: set_target_properties(foolib PROPERTIES COMPILE_OPTIONS "$<$:-Wl$no-undefined>" ) That is fixable if we choose a different parameter separation character (and port $ and $ to it too). Colon is not an option because it makes the language more confusing, and would require a $, which would need to be broadly used to escape 'Qt5::Core' etc. Looking at my keyboard, how about '?' '|' '\'' '#' or '*'? $*$> $|$> $'$> $#$> $?$> I prefer '*' because '?' doesn't stand out enough and :a?b seems wrong. '|' means OR more strongly to me than '*' would mean multiply in this context, and stands out well. '#' might work too, but I think it would be parsed as a comment if the whole expression was not surrounded in quotes? Thanks, Steve. -- 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] New find module: FindGLEW.cmake
Am Mittwoch, 29. August 2012 um 19:54:58 schrieb Alexander Neundorf: > On Wednesday 29 August 2012, Benjamin Eikel wrote: > > Dear CMake developers, > > > > I have written a find module for the OpenGL Extension Wrangler (GLEW) [1] > > library (see attachment). I tried to follow all the instructions that I > > have found. I am willing to maintain that module. Unfortunately, the > > header file "glew.h" does not contain any version information. I could > > Cool :-) > From looking a bit around on the web, it seems other alternative names for > the glew library are "glew" and "glew32s" > Maybe you can add those two names to the find_library() call ? You are right, I was able to find both in GLEW's Makefile. "glew32s" is the name of the static library. I will add both of them. Thank you. > > > extract version information using PkgConfig, but I have in mind that > > using PkgConfig is discouraged. I am looking forward to your feedback. > > If possible, it'd be nice to do that without pkg-config, that's right. > glew.h on my system contains several version-related macros, isn't any of > these usable ? > > /usr/include/GL$ grep VERSION * > ... > glew.h:/* - GL_VERSION_1_1 > */ > glew.h:#ifndef GL_VERSION_1_1 > glew.h:#define GL_VERSION_1_1 1 > glew.h:#define GL_VERSION 0x1F02 > glew.h:#define GLEW_VERSION_1_1 GLEW_GET_VAR(__GLEW_VERSION_1_1) > glew.h:#endif /* GL_VERSION_1_1 */ > glew.h:/* - GL_VERSION_1_2 > */ > glew.h:#ifndef GL_VERSION_1_2 > glew.h:#define GL_VERSION_1_2 1 > glew.h:#define GLEW_VERSION_1_2 GLEW_GET_VAR(__GLEW_VERSION_1_2) > glew.h:#endif /* GL_VERSION_1_2 */ > glew.h:/* GL_VERSION_1_2_1 > --- */ > glew.h:#ifndef GL_VERSION_1_2_1 > glew.h:#define GL_VERSION_1_2_1 1 > glew.h:#define GLEW_VERSION_1_2_1 GLEW_GET_VAR(__GLEW_VERSION_1_2_1) > glew.h:#endif /* GL_VERSION_1_2_1 */ > glew.h:/* - GL_VERSION_1_3 > */ > glew.h:#ifndef GL_VERSION_1_3 > glew.h:#define GL_VERSION_1_3 1 > glew.h:#define GLEW_VERSION_1_3 GLEW_GET_VAR(__GLEW_VERSION_1_3) > glew.h:#endif /* GL_VERSION_1_3 */ > glew.h:/* - GL_VERSION_1_4 > */ > glew.h:#ifndef GL_VERSION_1_4 > glew.h:#define GL_VERSION_1_4 1 > glew.h:#define GLEW_VERSION_1_4 GLEW_GET_VAR(__GLEW_VERSION_1_4) > glew.h:#endif /* GL_VERSION_1_4 */ > glew.h:/* - GL_VERSION_1_5 > */ > glew.h:#ifndef GL_VERSION_1_5 > glew.h:#define GL_VERSION_1_5 1 > glew.h:#define GLEW_VERSION_1_5 GLEW_GET_VAR(__GLEW_VERSION_1_5) > glew.h:#endif /* GL_VERSION_1_5 */ > glew.h:/* - GL_VERSION_2_0 > */ > glew.h:#ifndef GL_VERSION_2_0 > glew.h:#define GL_VERSION_2_0 1 > glew.h:#define GL_SHADING_LANGUAGE_VERSION 0x8B8C > glew.h:#define GLEW_VERSION_2_0 GLEW_GET_VAR(__GLEW_VERSION_2_0) > glew.h:#endif /* GL_VERSION_2_0 */ > glew.h:/* - GL_VERSION_2_1 > */ > glew.h:#ifndef GL_VERSION_2_1 > glew.h:#define GL_VERSION_2_1 1 > glew.h:#define GLEW_VERSION_2_1 GLEW_GET_VAR(__GLEW_VERSION_2_1) > glew.h:#endif /* GL_VERSION_2_1 */ > glew.h:/* - GL_VERSION_3_0 > */ > glew.h:#ifndef GL_VERSION_3_0 > glew.h:#define GL_VERSION_3_0 1 > glew.h:#define GL_MAJOR_VERSION 0x821B > glew.h:#define GL_MINOR_VERSION 0x821C > glew.h:#define GLEW_VERSION_3_0 GLEW_GET_VAR(__GLEW_VERSION_3_0) > glew.h:#endif /* GL_VERSION_3_0 */ > glew.h:/* - GL_VERSION_3_1 > */ > glew.h:#ifndef GL_VERSION_3_1 > glew.h:#define GL_VERSION_3_1 1 > glew.h:#define GLEW_VERSION_3_1 GLEW_GET_VAR(__GLEW_VERSION_3_1) > glew.h:#endif /* GL_VERSION_3_1 */ > glew.h:/* - GL_VERSION_3_2 > */ > glew.h:#ifndef GL_VERSION_3_2 > glew.h:#define GL_VERSION_3_2 1 > glew.h:#define GLEW_VERSION_3_2 GLEW_GET_VAR(__GLEW_VERSION_3_2) > glew.h:#endif /* GL_VERSION_3_2 */ > glew.h:/* - GL_VERSION_3_3 > */ > glew.h:#ifndef GL_VERSION_3_3 > glew.h:#define GL_VERSION_3_3 1 > glew.h:#define GLEW_VERSION_3_3 GLEW_GET_VAR(__GLEW_VERSION_3_3) > glew.h:#endif /* GL_VERSION_3_3 */ > glew.h:/* - GL_VERSION_4_0 > */ > glew.h:#ifndef GL_VERSION_4_0 > glew.h:#define GL_VERSION_4_0 1 > glew.h:#define GLEW_VERSION_4_0 GLEW_GET_VAR(__GLEW_VERSION_4_0) > glew.h:#endif /* GL_VERSION_4_0 */ > glew.h:/* - GL_VERSION_4_1 > */ > glew.h:#ifndef GL_VERSION_4_1 > glew.h:#define GL_VERSION_4_1 1 > glew.h:#define GLEW_VERSION_4_1 GLEW_GET_VAR(__GLEW_VERSION_4_1) > glew.h:#endif /* GL_VERSION_4_1 */ Th
Re: [cmake-developers] New find module: FindGLEW.cmake
Am Mittwoch, 29. August 2012 um 18:53:51 schrieb Brad King: > On 08/29/2012 05:43 AM, Benjamin Eikel wrote: > > I have written a find module for the OpenGL Extension Wrangler (GLEW) [1] > > library (see attachment). I tried to follow all the instructions that I > > have found. I am willing to maintain that module. > > Great, thanks for your work! > > Please proceed through steps 5 and 6 here: > > http://www.cmake.org/Wiki/CMake:Module_Maintainers#New_Maintainer > > You're welcome to work on other modules (like SDL) as well, but > please bring up changes for discussion on the list with the > current maintainer of each. > > > "glew.h" does not contain any version information. > > It looks like there are version "macros" that evaluate to runtime > tests. How is one supposed to do any preprocessor conditionals > based on the version when using GLEW? I do not know of any preprocessor tests. There is a possiblity at runtime to call "glewGetString(GLEW_VERSION)", but I think it would be too resource intensive to compile and run an application in the find module. > > > I could extract version information using PkgConfig, but I have in > > mind that using PkgConfig is discouraged. > > There is nothing wrong with using PkgConfig when it is available, > but it does not work for all toolchains on all platforms we support. > > -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
Re: [cmake-developers] conditionals in generator expressions
Brad King wrote: > On 08/27/2012 05:38 AM, Stephen Kelly wrote: >> Yes, I can see how the language could be able to offer both. However, I >> do think that the built-in 'this' target should be the one that the >> generator expression is evaluated on. > > Okay. I'd just like to reserve room in the syntax to allow the target > to be specified explicitly in $. Ideas? It's probably clear already from looking at the branch, but my idea is this: " $ = The value of the property prop on\n" \ "the target on which the generator expression is evaluated.\n"\ " $ = The value of the property prop\n" \ "the target tgt.\n" \ I've updated the branch to implement the TODO I had left there for this, but I haven't tested it. It shows the intent, even if it has a bug :). Thanks, Steve. -- 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] Depends for Qt .qrc files.
Brad King wrote:
> - file(READ "${infile}" _RC_FILE_CONTENTS)
> + file(STRINGS "${infile}" _RC_FILE_CONTENTS REGEX
> "]*>[^<]+")
Only this needed to be reverted. I added it to Qt4Macros-fix-resource-
parsing.
Thanks,
Steve.
--
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
