RE: [CMake] improve the CMake language?
It is my understanding that a lot of the cmake modules are implemented in the cmake language? It would be a big task to maintain multiple languages for the cmake modules. While speed of a scripting language is interesting, I would expect 90% of the work would be done in the C++ part of cmake. I would think BSD type licensing and compactness would be more important. Juan -Original Message- From: [EMAIL PROTECTED] on behalf of Gonzalo Garramuño Sent: Mon 11/5/2007 4:55 PM To: Ken Martin; CMake ML; Sanchez, Juan Subject: Re: [CMake] improve the CMake language? Ken Martin wrote: I have looked at incorporating Lua into CMake as an alternate language. Interesting. You didn't by any chance used swig to wrap it? I admit I would be curious to see that fork of cmake to study the changes. Using swig right now would be the best approach, as with just a few swig rules (if any) it would allow any user to choose whatever language he feels like using. Currently, swig supports all languages mentioned in this thread so far and it works pretty well for projects like cmake where its .h files keep changing. Eventually one scripting language could end up becoming massively more popular and be adopted as a standard for cmake. But I'm betting in the future that won't matter, as several vendors are developing tools or frameworks to offer data interchange across the major scripting languages. -- For those that don't know Lua, Lua has a very similar syntax to non-OO ruby albeit parenthesis are required. It is also very fast, small and, just like TCL, thread safe and built for embedding (python and ruby still struggle with threads). LuaJIT is probably one of the fastest JIT compilers for a dynamic language under any platform. Lua's uglyness is its OO support and syntax, which is closer to OO Javascript or Perl's. -- P.S. Disclosure: I am swig's ruby maintainer. -- Gonzalo Garramuño [EMAIL PROTECTED] AMD4400 - ASUS48N-E GeForce7300GT Kubuntu Edgy ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] improve the CMake language?
Tcl is a nice language for implementing declarative commands. It can be easily
built on about every platform out there, and the language rules are well known.
It is small, and very easy to compile a standalone Tcl based interpreter with
the CMake commands built in. The user would not need to have any language
installed, you could package the source with CMake or make it part of the cmake
binary you distribute. It is freely distributable and has a BSD license.
add_library(foo SHARED foo.cxx)
could become
add_library {foo SHARED foo.cxx}
or even
add_library -name foo -type SHARED foo.cxx
Please see:
http://en.wikipedia.org/wiki/Tcl
for a description of this language. It would be very easy to implement a macro
as a procedure.
I would be happy to participate in any effort to port the cmake commands to a
Tcl interpreter. Please let me know if you are interested.
Regards,
Juan
-Original Message-
From: [EMAIL PROTECTED] on behalf of Bill Hoffman
Sent: Thu 11/1/2007 8:03 PM
To: Brandon Van Every
Cc: cmake@cmake.org
Subject: Re: [CMake] improve the CMake language?
Brandon Van Every wrote:
My concern is that if the status quo is maintained, CMake script will
always be ugly to program with. This will put it at a disadvantage
compared to build systems written in Python, Ruby, or Perl. I'm not
just talking about SCons and so forth. I'm talking about a shop
deciding, hey, screw this off-the-shelf stuff, we'll write our own
custom build system in our favorite scripting language. It happens in
the game industry all the time.
Your thoughts?
CMake is a build system. In an ideal world, the language would be
purely declarative. Basically, you would describe things you want to
build, and CMake would build them. In practice, this is too
restrictive, and a small amount of programming makes things easier. I
never wanted CMake to replace perl, ruby, python or any other language.
I wanted CMake to not depend on another language being installed. CMake
only depends on a C++ compiler being around, so CMake can be built.
Since CMake was developed for ITK (a c++ toolkit), I was adding no
additional restrictions to the build process. The scripting stuff
actually came out of a desire to automate the testing system without the
use of tcl as was required in earlier version of Dart. I am sure the
CMake language will be tweaked here and there, but if you have a big
programming job that has nothing to do with building software, then
CMake is the wrong choice.
So, I think that if something is hard to build because of the CMake
language, then we should fix it. People should use CMake because it is
really easy to build complex things with, and not because it has a great
language. The hard stuff should be done in C++ commands.
For example, this small line of CMake code:
add_library(foo SHARED foo.cxx)
does some very complicated stuff as it builds shared libraries on many
platforms, and different IDE's. And most of that is not done with the
CMake language, it is done with the more powerful C++ language. BTW, I
hope this does not become a long discussion, but I am sure it will...
-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] improve the CMake language?
Hello Bill,
add_library(foo SHARED foo.cxx)
won't work.
Parenthesis are not part of the standard syntax, and worth getting Tcl to
understand them.
Tcl is a simple language, and is well understood. It has already been ported
to about every platform out there. You don't need QT or wxWidgets, because the
Tk extensions of it already work.
Many features in the CMake language don't really work the way people expect, or
are not documented, or both.
If anyone would like to fork cmake with me, I'm game.
Features:
Tcl frontend featuring modern dynamic language constructs and consistent syntax.
C pre-processor based dependency scanner
Accurate and up to date documentation
Focus on getting build system that works, because all of the language
constructs have already been written.
Developers who are not hostile to ideas concerning improvements to the language.
Regards,
Juan
-Original Message-
From: Bill Hoffman [mailto:[EMAIL PROTECTED]
Sent: Thu 11/1/2007 9:18 PM
To: Sanchez, Juan
Cc: Bill Hoffman; Brandon Van Every; cmake@cmake.org
Subject: Re: [CMake] improve the CMake language?
Sanchez, Juan wrote:
Tcl is a nice language for implementing declarative commands. It can be
easily built on about every platform out there, and the language rules
are well known. It is small, and very easy to compile a standalone Tcl
based interpreter with the CMake commands built in. The user would not
need to have any language installed, you could package the source with
CMake or make it part of the cmake binary you distribute. It is freely
distributable and has a BSD license.
add_library(foo SHARED foo.cxx)
could become
add_library {foo SHARED foo.cxx}
or even
add_library -name foo -type SHARED foo.cxx
I can't help myself, I have to respond :)
Or it could be:
add_library(foo SHARED foo.cxx)
Hey, wait, that already works... :)
The point is you don't need tcl, python, or ruby to add add a library.
You need a simple language, and I want it to work with only a c++
compiler and its standard libraries. So, when someone wants to build a
c++ program with CMake on a new platform, they don't first have to port
(tcl/python/ruby/XXX), the just need to have a c++ compiler, which they
should have if they are building a c++ application. It is sort of a
prerequisite to have a c++ compiler to build a c++ application, so we
know it will be there.
Sorry Juan, your suggestion is valid, and perhaps I should create a FAQ
entry like: Why the CMake Language? So, I can point to it when this
comes up.
-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] Nonstandard architectures.
If you want to check without actually compiling. There is the file command which can tell you about a shared library or any other file on your filesystem. ~ file /opt/firefox/libfreebl3.so /opt/firefox/libfreebl3.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), stripped ~ file /usr/lib64/nss/libfreebl3.so /usr/lib64/nss/libfreebl3.so: symbolic link to `libfreebl3.so.11' ~ file /usr/lib64/nss/libfreebl3.so.11 /usr/lib64/nss/libfreebl3.so.11: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), stripped Barring that, I've seen people use chroot jails to contain their 32 bit compile environments. Juan -Original Message- From: [EMAIL PROTECTED] on behalf of Mathias Froehlich Sent: Thu 9/27/2007 4:12 AM To: cmake@cmake.org Subject: [CMake] Nonstandard architectures. Hi, I have problems with nonstandard architectures. cmakes mechanism to see if some package is installed usually just looks if some files are present. That is good as long as you just compile for the standard architecture on a specific operating system. But if I build for some non default architecture (for example for 64 bit pa risc instead of the 32 bit default one). Most configury checks will not find the truth. For example, In my amd64 linux system we have a /usr/local/lib/libglut.so. so the FIND_PACKAGE(GLUT) will see: 'ah we have glut available!'. But when I build for emt64, this is just wrong, because I do not have the equivalent /usr/local/lib64/libglut.so installed ... Old autoconf used to check existence of libraries by compiling a small test example with the configured compiler and link against that library in question. In contrast to cmake that just looks for the existence of files. This way one could be sure that this fits together. This would be for sure one solution to that problem. An other one would be to use the 'correct' standard librarie paths for different architectures. But that means that cmake will need to know more about the ABI in use. Currently this is not required to know. What to do here? Greetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Florian Geyer, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Prof. Dr. Hanns Ruder Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] Creating a static lib from other static libs, HOW?
Could you post the link to the faq? I don't see which question covers the topic. Juan -Original Message- From: [EMAIL PROTECTED] on behalf of Brandon Van Every Sent: Mon 9/17/2007 1:10 AM To: cmake@cmake.org Subject: Re: [CMake] Creating a static lib from other static libs, HOW? On 9/16/07, Juan Sanchez [EMAIL PROTECTED] wrote: Hello, The ar command can be used to extract the .o files from a .a file. Extracting them all into the same directory, perhaps you can use some file globbing to find all the objects and add them to another archive. Yeah but that's the ar command, which is specific to Unixy systems. Doesn't help a cross-platform build solution that includes MSVC. I just got done telling all you guys how to reuse objects in a platform independent manner. And it's in the FAQ now for handy reference. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] Turning on warnings when compiling.
ADD_DEFINITIONS(-Wall) should work for both the gnu c and c++ compiler and other compilers supporting gnu option emulation. You can also do: make VERBOSE=1 on a unix system to see the commands being executed. Regards, Juan -Original Message- From: [EMAIL PROTECTED] on behalf of Michael Wagner Sent: Tue 8/28/2007 8:07 AM To: cmake@cmake.org Subject: [CMake] Turning on warnings when compiling. Hi, Whenever I'm compiling, there are no warnings shown. Is there a command or variable that can be used to turn on warnings? When searching the wiki, the only information I found was this page: http://www.cmake.org/Wiki/CMake_Platform_Dependent_Issues which tells me the right flags for all the different compilers. That is wonderfull, I just need to know how to turn that stuff on! Maybe somebody out there knows how to turn on warnings. (Hopefully you are not all fearless coders that laugh in the face of warnings... ;-) cheers, Michael ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] -DCMAKE_C_COMPILER:string=g++
Note that many C/C++ compilers rely on the file extension to determine whether it should be processed using C or C++. I tested this a file with a simple function and with the following extensions on linux 32 bit and looked at the symbols using nm. For gcc -c .c unmangled .C mangled .cc mangled For g++ -c .c mangled .C mangled .cc mangled I don't have the intel compiler handy, but I think I remember it uses the same binary for C and C++ compilation and relies very much on the file extension. Regards, Juan -Original Message- From: [EMAIL PROTECTED] on behalf of Bill Hoffman Sent: Wed 8/8/2007 8:52 PM To: Marie-Christine Vallet; cmake Subject: Re: [CMake] -DCMAKE_C_COMPILER:string=g++ Marie-Christine Vallet wrote: Bill Hoffman wrote: Marie-Christine Vallet wrote: Hi, I would like to use g++ as my c compiler (which works) but cmake does not let me do that. Is this normal? Thanks again, Marie I suspect you want to look at LINKER_LANGUAGE. You really don't want to use g++ for a c compiler. What are you trying to do? -Bill one of the c files includes a c++ file that is why I need to compile my c files with g++ and not gcc. One of the solution would be to rename my c file cpp or cxx thanks, Marie You can also set the language for that .c file to CXX. set_source_file_properties(foo.c PROPERTIES LANGUAGE CXX) -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
