Este projeto é baseado em um componente para editor de texto, o Scintilla (um componente muito poderoso), escrito em C++ com pura api win32 e STL (o que garante alta velocidade de execução e pequeno tamanho de programa), está sob a licença da GPL.

Veja abaixo as características do Notepad++ :

1) Destaque de Sintaxes e Sintaxe de Blocos

Linguagens suportadas :

C, C++, Java, C#, XML, HTML, PHP, CSS, makefile, ASCII art (.nfo), doxygen, ini file, batch file,  Javascript, ASP, VB/VBS, SQL, Objective-C, RC resource file, Pascal, Perl, Python,  Lua, TeX, TCL, Assembler, Ruby, Lisp, Scheme, Properties, Diff, Smalltalk, Postscript, VHDL, Ada, Caml, AutoIt, KiXtart, Matlab, Verilog, Haskell, InnoSetup, CMake, YAML.

2) WYSIWYG (O que você vê é o que você tem)

Se você tiver uma impressora colorida poderá imprimir seu código fonte (ou qualquer outra coisa) em cores.

3) Destaque de Sintaxes Definida pelo Usuário

Isto permite ao usuário definir sua própria linguagem: não somente sintaxe de palavras chaves, mas também sintaxe de blocos (ex : If / endIf) , comentários e operadores. ( imagem1, imagem2, imagem3, imagem4 ).

4) Auto completar

Para quase todas as linguagens suportadas, o usuário pode criar sua própria lista de api (ou baixar os arquivos na sessão download). Uma vez que o arquivo api estiver pronto, digite Ctrl+Espaço para executar esta ação (veja a imagem). Para mais informações sobre o auto completar, por favor veja a sessão Auto completar.

5) Múltiplos Documentos

Você pode editar vários documentos ao mesmo tempo.

6) Múltiplas Visualizações

Você tem duas visualizações ao mesmo tempo. Na qual você poderá visualizar/editar 2 documentos diferentes ou o mesmo documento (imagem). Você pode visualizar (editar) em 2 vistas um documento, em posições diferentes. A modificação de uma das vistas acontecerá na outra também. (ou seja, você modifica o MESMO documento quando você está no modo clone, veja a imagem).

7) Suporta Expressões de Busca/Substituição

Você pode buscar a substituir uma string (frase) no documento usando expressões regulares.

8 ) Suporta o Arrastar e Soltar

Você pode abrir um documento arrastando e soltando. Você pode também mover seu documento (ou visualização) de uma posição a outra usando o Arrastar e Soltar.

9 ) Posição Dinâmica de Visualizações

O usuário pode escolher a posição de uma visualização dinamicamente (somente em 2 modos : separação horizontal ou vertical), veja a imagem.

10) Auto detecção de Estado do Arquivo

Se você modificar ou apagar um arquivo que esteja aberto no Notepad++, você receberá uma notificação para atualizar seu documento (recarregar o arquivo ou apagar o arquivo).

11) Avanço/Recuo de Zoom

Esta é uma outra fantástica função do componente Scintilla. Simplesmente veja a imagem.

12) Ambiente com Suporte a Múltiplos Idiomas

O chinês, japonês, coreano, árabe e hebraico são suportados no ambiente Windows. Veja o Notepad++ sob o Chinês - Windows , sob o Árabe - Windows e sob o Hebraico - Windows em ação.

13) Marcadores

Basta clicar na margem para inserir um marcador (no lado direito da margem junto ao nº da linha) ou digitar Ctrl+F2 para inverter o marcador. Para ir até um marcador, digite F2 (Próximo Marcador) ou Shift+F2 (Marcador Anterior). Para excluir todos os marcadores, clique no Menu Localizar->Excluir Marcadores. Veja a imagem.

14) Chaves, Colchetes e Parênteses com Destaque

Quando o cursor se apróxima de um desses símbolos { } [ ] ( ) , o símbolo que está próximo ao cursor e o símbolo simetricamente oposto são destacados, assim como sua guia de identação (se houver) fazendo com que a localização de um bloco seja mais fácil. Veja a imagem1,  imagem2 .

15) Grava e Reproduz Macros

Você pode salvar várias macros e criar atalhos de tecla para o próximo uso.

DOWNLOAD: Para baixar o programa Notepad++ (v.5.0) e obter maiores detalhes sobre  arquivos de ajuda, arquivos de api, arquivos binários, arquivos de estilos, arquivos de imagens, códigos fonte, temas, plugins,  vá diretamente do site do desenvolvedor: clicando aqui

Já existe a versão 5.0.1 do programa Notepad++ disponível no Baixaki, porém, testamos o executável e o mesmo apresentou erro na hora da instalação, assim, não disponibilizaremos o link dessa versão.

O programa tem 2,03MB, não possui limitações, é totalmente gratuito e funciona nos sistemas: Windows XP/98/2000.

]]> http://uncleham.wordpress.com/?p=99 Sat, 19 Jul 2008 18:03:30 +0000 Dave Smith http://uncleham.wordpress.com/?p=99 There's evidence that CMake may be overtaking Autotools as the cross-platform build tool of choice in the open source community.

Google Trends indicates that CMake has recently overtaken Automake in search volume, and here's an insightful article about why KDE switched to CMake during the KDE 4.0 development cycle.

Primero en la version 2.6 de cmake han actualizado algo que hace fallen los archivos de cmake de OSG, por tanto os recomiendo que utiliceis la versión 2.4.8 (si teneis compilada una 2.5.X es probable que también os funcione sin problemas) aunque igual puede que os funcione con la 2.6 modificando la compatibilidad a 2.5.

Una vez tenemos la versión correcta de cmake, vamos al directorio donde tenemos los fuentes de OSG (la carpeta OpenSceneGraph) y nos creamos un directorio (Build por ejemplo) para dejar la basurilla que genera la compilación ahi:

$ cd OpenSceneGraph

$ mkdir Build

$ cd Build

Desde el directorio Build ejecutamos cmake para que nos genere los makefiles:

$ ccmake ../

o si queremos que genere un proyecto de Xcode en lugar de los makefiles:

$ ccmake ../ -GXcode

La primera vez que ejecutemos ccmake genera un archivo de cache donde se almacenan las opciones que hemos marcado. Como es la primera vez, nos preguntara que tipo de compatibilidad queremos, por defecto pone la de version de cmake que tenemos instalada. Para que funcione OSG debeis de tener puesto 2.4.8 si teneis esta version de cmake o 2.5 si teneis una superior.

A continuación pulsaremos la letra "c" y nos creara una configuracion por defecto. Para movernos por la tabla utilizaremos los cursores y pulsando Intro podemos modificar el valor de cada una de las celdas. Debemos marcar a ON: BUILD_OSG_APPLICATIONS, BUILD_OSG_EXAMPLES, BUILD_OSG_PLUGINS y si ademas vamos a trabajar con introspección debemos poner a ON: BUILD_OSG_WRAPPERS.

En CMAKE_INSTALL_PREFIX le indicaremos la ruta donde queremos que instale las librerias o dejaremos el valor que trae por defecto. Con CMAKE_OSX_ARCHITECTURES podemos especificar con que arquitecturas queremos que sea compatible la librería, por defecto "ppc; i386".

La opción CMAKE_OSX_SYSROOT indica que SDK se va a utilizar para la compilación. Por defecto se utiliza el 10.5 que es el de Leopard, pero para mantener la compatibilidad con Tiger cambiaremos su valor por: /Developer/SDKs/MacOSX10.4u.sdk

El parametro DYNAMIC_OPENSCENEGRAPH y DYNAMIC_OPENTHREADS nos permiten decididir si queremos las librerías dinámicas (por defecto) o estáticas.

A partir de aqui aparecen las rutas de un monton de librerías que son dependencias externas de OSG. No es necesario tenerlas todas, pues algunas son para algunos plugins concretos y normalmente si las tenemos instaladas en el sistema, cmake las encuentra el solo.

Bueno con esto solo debería compilar sin más problemas, pero lamentablemente no es así. Con esta configuración da un error al compilar Tessellator.cpp. Para solucionarlo debemos cambiar el parametro OSG_GLU_TESS_CALLBACK_TRIPLEDO a OFF. En mi caso particular, tampoco podia compilar el ejemplo de wxWidgets porque me falta alguna librería, si como yo no vais a utilizar el plugin de Widgets basta con que os asegureis que wxWidgets_CONFIG_EXECUTABLE y wxWidgets_wxrc_EXECUTABLE ponga NOTFOUND (sino poneis un espacio en blanco y listo). Si quereis usarlo podeis mirar las dependencias en la pagina de OSG e instalarlas.

Si estais en Leopard os dara también un error de "reexpots" libGL. Para solucionar este error basta con pulsar "t" en ccmake para entrar en modo de edición avanzado. Una vez en modo avanzado (veremos que salen nuevas opciones) buscamos la que se llama CMAKE_MODULE_LINKER_FLAGS y copiamos la siguiente linea (atención debe ir toda en una única linea):

-dylib_file /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib:
/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/OpenGL.framework
/Versions/A/Libraries/libGL.dylib

o si estamos compilando con el SDK 10.5:

-dylib_file
/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib:
/Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks/OpenGL.framework
/Versions/A/Libraries/libGL.dylib

Una vez añadida la linea, pulsamos de nuevo "t"para volver al modo normal. Ahora pulsamos "c" para ajustar la configuración a las nuevas opciones y "g" para generar los makefiles o el proyecto de Xcode.

Y ya esta listo para compilar con make install si hemos generado makefiles o con el proyecto de Xcode.

Espero que os sirva de ayuda. XD

メーリングリストを見るとアセンブリファイルのサポートはまだ実験段階らしい。まあ、そんなことは気にせずに使う。

CMakeLists.txt:
  cmake_mininum_required(VERSION 2.6)
  enable_language(ASM)

これでアセンブリファイルを認識するようになる。

標準の状態ではCMakeはアセンブリファイルに対してATTのアセンブラ、つまりGASを起動する。今やっているプロジェクトはアセンブリファイルをCコンパイラに処理させたいのでカスタマイズが必要になる。アセンブリファイルに異なるアセンブラを割り当てたい。

CMakeLists.txt:
  cmake_mininum_require(VERSION 2.6)
  set(CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR}/MyCMake}
  enable_language(ASM-GCC)
  set(CMAKE_ASM-GCC_COMPILER_ARG1 -c) # invoke gcc with "-c"

MyCMake/CMakeASM-GCCInformation.cmake:
  set(ASM_DIALECT "-GCC")
  set(CMAKE_ASM${ASM_DIALECT}_SOURCE_FILE_EXTENSIONS s;S)
  include(CMakeASMInformation)
  set(ASM_DIALECT)

MyCMake/CMakeDetermineASM-GCCCompiler.cmake:
  set(ASM_DIALECT "-GCC")
  set(CMAKE_ASM${ASM_DIALECT}_COMPILER_INIT ${_CMAKE_TOOLCHAIN_PREFIX}gcc ${_CMAKE_TOOLCHAIN_PREFIX}cc)
  include(CMakeDetermineASMCompiler)
  set(ASM_DIALECT)

MyCMake/CMakeTestASM-GCCCompiler.cmake:
  set(ASM_DIALECT "-GCC")
  include(CMakeTestASMCompiler)
  set(ASM_DIALECT)

これでアセンブリファイルをgccでコンパイルできるようになった。

The compilation problem lies the source code of the Qt demo. Two other classes were declared in two of the class definition .cpp files so that either moc'ing the sources or moc'ing the headers will leave some of Q_OBJECT classes un-moc'ed, which causes the linking errors. On the other hand, qmake handles this implicitly so the project file it generates doesn't have this problem. After moving those declarations to the header files, everything compiled nicely and quietly.

As for the debug execution problem, Bill also suggested that the commercial evaluation version of Qt 4 binary I downloaded might be built with VS 2005. If that is the case, there is no way I can execute in debug mode the program linked against the Qt 4 libraries. I was just being so naive to make the assumption that the binaries should be of no difference if QMAKESPEC is the same.

After downloading and compiling the source of Qt 4.4 beta (boy, that compilation DID take QUITE a while), everything went back to normal. I am now happily "CMaking" my projects again.

The demo that comes with the package looks really appealing, just like how I like it: simple, themed design and fluent animated transition, which together provide the user with maximum visual satisfaction.

Trolltech is generous enough to have included all the source code of the demo so that we can play around and figure out how to mimic those fancy effects. At first I planned to use CMake to generate the project file (.sln file in the case of Visual Studio) for the demo, in accordance with all other projects that I am working on. There are also examples of CMakeLists.txt for Qt 4 projects (here is one). Despite it seemed that everything should be easily done without any hustle, it soon turned out not to be the case this time.

First, the solution file generated by CMake just won't compile (unless it's a single main.cpp, in which case I got it to work) if there are other Q_OBJECT classes present. I tried both QT4_AUTOMOC and QT4_WRAP_CPP, all ended up with "error LNK2019: unresolved external symbol":

SET(SRCS src/main.cpp src/mainwindow.cpp)
SET(HDRS include/mainwindow.h)

and either

QT4_AUTOMOC(${SRCS})
ADD_EXECUTABLE(demoGUI ${SRCS} ${HDRS})

or

QT4_WRAP_CPP(MOC_SRCS ${HDRS})
ADD_EXECUTABLE(demoGUI ${SRCS} ${HDRS} ${MOC_SRCS})

Correct me if I am doing anything wrong above. After googling a bit I figured that something is wrong with the moc'ing process, but I haven't yet found a solution. Thus I am taking CMake out of the equation temporarily.

A nice thing about qmake that comes with the Qt package is that just like CMake it can generate project files for different platforms, with an equivalent of CMakeLists.txt, projectname.pro file. With the command

qmake -tp vc -spec win32-msvc2005

one can easily get the project file (.vcproj/.sln) for Visual Studio 2005 to use. The project compiled under VS 2008 without any error, but when running under debug mode I get either "This application has failed to start because the application configuration is incorrect" if the solution file is generated by qmake or "The application failed to initialize properly (0xc0150002)" if it is created by CMake (remember I had one single main.cpp compiled). However, the release builds executed correctly.

Again I googled for a while and found out the problem might lie in the manifest files of the Qt core dll's. Since the QMAKESPEC is set to win32-msvc2005, the manifest files of the dll's have VS 2005 info (Microsoft.VC80.DebugCRT) embedded. When the program compiled with VS 2008 (VC90) and linked against those dll's tries execute, there's a conflict in configuration. Unfortunately, none of the solutions I found worked.

Now it is quite clear that for now I cannot (at least easily) debug the Qt4 programs in VS 2008. VS 2005, on the other hand, is working as advertised both in debug and release mode. Guess I would have to stick with VS 2005 for a while before Qt 4.4 is released.

An alternative plan would be trying out the 4.4 beta to see if it is a solution, while using qmake to generate the Makefile, from which to see how the CMakeLists.txt should be written.

Questo software rimpiazza il vecchio e non facilissimo da usare Automake nella generazione dei Makefile. Infatti, nella maggior parte dei progetti, non esiste un Makefile incluso nei sorgenti, dato che questo non è portabile. Per la compilazione del programma è necessario verificare che siano incluse tutte le librerie e scovare i loro percorsi all'interno del file system. Proprio per questo motivo, è impossibile avere un Makefile già scritto. A questo punto, il tool Automake, doveva eseguire una precisa ricerca di tali librerie e infine, se non si sono riscontati errori, la definitiva creazione del Makefile per la successiva compilazione.

Questo avveniva con:

./configure
make
make install

La creazione di un configure non è proprio facilissima. Proprio per questo interviene il nuovo sistema di generazione di Makefile: CMake.
Utilizzo

CMake è un tool molto modulare che, con poche e concise istruzioni, è in grado di generare Makefile a puntino. CMake dispone di una particolare sintassi comprensiva di moltissime macro ed il loro utilizzo è possibile mediante un apposito file chiamato CMakeLists.txt.

Un tipico e semplicissimo esempio di CMakeLists.txt è il seguente:

PROJECT(matematica)

ADD_DEFINITIONS(-pipe -O2 -mtune=native)

ADD_EXECUTABLE(
../bin/matematica
src/main.cpp
)

Per la generazione del Makefile e la successiva compilazione del progetto, è necessario eseguire i seguenti comandi:

mkdir build
cd build
cmake ..
make

I primi due comandi possono essere anche evitati, ma in questo modo si evita di sporcare il progetto, così da avere tutto ciò che serve per la compilazione, all'interno della directory build.

Mediante CMake si crea effettivamente un Makefile astratto, mentre la sua creazione concreta avviene nel particolare sistema operativo utilizzato.
Applicazioni che usano CMake

• KDE (partendo dalla versione 4)
• VTK
• OpenSceneGraph
• Scribus
• Quantum GIS

Ieri mi sono finalmente deciso a ricompilare KDE 4 da SVN e quindi a compilare anche la nuova versione (ancora in stato preview) delle librerie grafiche Qt, la 4.4. Non vi sono stati intoppi durante la il processo e già così mi sono sentito sollevato, dato che mi aspettavo che qualcosa potesse andare storto, data appunto l'immaturità di questa nuova versione. Il desktop environment si è avviato correttamente e pian piano ho iniziato a notare alcuni piccoli difetti, ad esempio, quando si ridimensiona una finestra, questo non avviene immediatamente ma bisgona avviene una sorta di freeze della finestra che si ridimensiona solo dopo alcuni secondi (screenshot). Un altro problema lo si può riscontrare nelle caselle di testo mentre si usa konqueror. Infatti l'ultimo carattere digitato non viene visualizzato. Non so se questo sia dovuto al nuovo motore WeKit, poiché so che la nuova versione delle QT integra questo engine ma non so se sia già stato incluso in konqueror al posto di KHTML (e non è nemmeno facile notare la differenza). Inoltre, utilizzando hardy che integra di default il nuovo pulseaudio, phonon non ci lavora correttamente (ma questo è un problema di xine, il cui plugin per supportare pulseaudio è ancora immaturo e quindi disabilitato).
Speriamo che nel breve questi difetti vengano sistemati, ma di certo non me la prenderò se qualcosa non va, dato che siamo ancora distanti dal rilascio di KDE 4.1. :)

after you checkout SVNs in '/home/KDE4devel/SRCs/KDE/' you can just make another folder, let's say '/home/KDE4devel/Build/KDE/'
open Terminal/Konsole and then type:
su -
cd /home/KDE4devel/Build/KDE
cd kdelibs
cmake && make && make install
cd ..
cd kdepimlibs
cmake && make && make install
cd ..
cd kdebase
cmake && make && make install
cd ..
cd "yourmodule"
cmake && make && make install

OR if you have changed your .bashrc, you can do for each one:

cd /home/KDE4devel/SRCs/KDE/4.0/yourmodule
cmakekde

(it MIGHT work, I just made it up right now ;) )

WARNING: THIS WILL REPLACE YOUR KDE 3.5 DESKTOP.
WARNING: YOU WILL NEED ROOT PRIVILEGES.

If you try this one, leave comment for me whether if it worked for you or not. Thanks :)

go to your home directory and
View > Show hidden files
now if you look closely, you'll find a file called ".bashrc" among the hidden files.
open that with a text editor ( in 99% cases just double click it )

copy the .bashrc in you original home ( /home/username/ ) into your KDE4devel account ( /home/KDE4devel/ ) it should replace it.

copy/paste the contents of this .bashrc into your .bashrc, after "#user-specified commands" ( or something like that ).

now you're ready to go. By the way, this .bashrc you just did, was only to make life easier but it is in fact necessary and you HAVE TO do it ;)

Building kdelibs
the first module ( package ) you should make/compile, is kdelibs. You SHOULD make this first of all.
to compile kdelibs, just do this:

cd
cs
mkdir KDE && cd KDE
svn checkout svn://anonsvn.kde.org/home/kde/branches/KDE/4.0/kdelibs
cd kdelibs
cmakekde

note: cs is not a typo. you made this command available by editing your .bashrc file, look into that for more info.
for troubleshooting stuff look into here.

Building kdepimlibs
next comes the kdepimlibs. the recipe is this:

cs KDE
svn checkout svn://anonsvn.kde.org/home/kde/branches/KDE/4.0/kdepimlibs
cd kdepimlibs
cmakekde

again, for troubleshooting stuff go here.

Building kdebase
next goes to kdebase.
recipe:

cs KDE
svn checkout svn://anonsvn.kde.org/home/kde/branches/KDE/4.0/kdebase
cd kdebase
cmakekde

troubleshooting stuff -> here.

from now, you can build all of the modules you want with the same fashion. For a minimal KDE 4 session you only needed those 3 modules and that's all.
after you finished compiling all the modules you want, you just log out, and log in again, hopefully everything will be fine and you will have your KDE 4 session :D

Good Luck with your building :D ( building as in compiling ;) )
note: I got this information from here.

ok, here we have all the dependencies ready to go and there just remains our time to be spent on compiling KDE 4 itself :)
WARNING: THIS STEP MUST BE DONE IN ONLY NORMAL USER. NO ROOT USER PLEASE. IF IT NEEDS YOU TO ENTER ROOT PASSWORD, REVIEW AND SEE WHAT YOU HAVE DONE WRONG.

first thing you should do, is that you should make a new user account to be used by KDE 4 ( just in case ).
to do it, go to ( for KDE ) Kmenu > system > users and groups ( for GNOME ) System > Administration > users and groups

make a new account and login to that account ( simply log out, and then log in again )
make a new folder wherever you want ( definitely not in root folder ) that you put your sources in it.
for this "tutorial" I will use /home/KDE4devel/SRCs/
go to that folder and open a Terminal/Konsole which points to that folder by using this command

cd /home/KDE4devel/SRCs/KDE/

now, you should download the sources of KDE 4 into this folder you just created. if you want to use fancy names, call it check out SVNs ( es-vi-enz )
to do this, just open Terminal/Konsole and type:
1) svn co -N svn://anonsvn.kde.org/home/kde/trunk/KDE
2) svn co -N svn://anonsvn.kde.org/home/kde/branches/KDE/4.0

if you want it really new and cutting edge, go for the first one, but if you prefer to back down a little bit ( not really much difference though ) go for the second one. But generally I'd suggest second one ;)

now just type:

cd 4.0
svn list
svn up kdebase kdepimlibs kdelibs

if you want other packages also to be checked out, you can just put them in svn up. for example if you want to also checkout kdemultimedia and kdegraphics, you just type

svn up kdebase kdepimlibs kdelibs kdemultimedia kdegraphics (etc.)

wait for quite a long time till it finishes ;)

you have just downloaded the source code of KDE 4. Next post, will be about compiling KDE 4.
Good luck :D

For a very simple project the first thing to create would be the

CMakeLists.txt

The most basic of cmake files you would need to build an executable would contain three declarations.
project(), add_executable() and set.
project(projectname) holds the name of the project.
The set function lists files into a variable that is
set(varname main.cpp someotherfile.cpp andanother.cpp) would allow you to reference all those file with the statement ${varname}.
For make it is done the same as setting environment variables VARNAME=main.cpp someotherfile.cpp andanother.cpp and then is referenced using $(varname).For the example of building a main.cpp into an executable you would use something like this for a make file.

SRC=main.cpp
OBJ=main.o
appname : $(OBJ)
g++ -o appname $(OBJ)
main.o : $(SRC)
g++ -c $(SRC)

then you would run make and it will happily build your executable.

To build this minimal application with cmake you could use the following functions in a CMakeLists.txt

project(projectname)
set(varname sourcefiles).
add_executable(appname ${varname})

Applying this to our main.cpp example and using the name "myapp" for the final executable, it would look something like this

project(myproject)
set(myapp_SRC
main.cpp
)
add_executable(myapp ${myapp_SRC})

you would then type cmake . <-- notice the dot. This would build among numerous other things, a Makefile.
You then type make as usual and the application is built.
Now lets say you add another src file to your application say struct.cpp and want to build that into your application.
This is where cmake very early on starts to show how much more usefull it can be, and this is only a hint.
To build the new struct.cpp files code into our application you would have to alter the Makefile to to tell it how to build the new struct code, something like this

SRC=main.cpp
STRUCT_SRC=struct.cpp
OBJ=main.o struct.o
appname : $(OBJ)
g++ -o appname $(OBJ)
main.o : $(SRC)
g++ -c $(SRC)
struct.o : $(STRUCT_SRC) <-------- new struct code
g++ -c $(STRUCT_SRC)

However with the cmake example you would just add the source file into the CMakeLists.txt like

set(myapp_SRC
main.cpp
struct.cpp <------- just add this in
)
Then just run cmake . again to regenerate the Makefile.
Other usefull functions are building a library the command:

add_library(libname [SHARED | STATIC | MODULE source1 source2 ......] )

This will just build a library, just like that. For example if you want to build a library out of the files struct.cpp and anotherfile.cpp just add

add_library(struct SHARED struct.cpp anotherfile.cpp)

to your CMakeLists.txt file and run cmake on the current directory: cmake .
and you will see that libstruct.so has appeared there.

Addding

project(projectname)

to a CMakeLists.txt tells cmake to set a couple of variables namely projectname_BINARY_DIR and projectname_SOURCE_DIR but most importantly you will want to set this if you are building you application with a C compiler and not a C++ compiler.

I've downloaded the BOINC VMWare virtual machine and configured a local BOINC server with the uppercase sample application. I also downloaded the BOINC source code (including sample applications) and successfully compiled the sample applications for the i686-pc-linux-gnu, windows_intelx86 and windows_x86_64 platforms. Then I deployed the newly compiled application versions to the BOINC server and tested the one for windows_intelx86.

I encountered another strange problem with VC++ when I tried to compile the BOINC sample applications. Some "access denied" error kept showing up when VC++ tried to embed some manifest to the executables. It disappeared when I turned off manifest embedding. Later when I had successfully compiled all the sample applications I turned the manifest embedding back on and the problem was nowhere to be seen. Standard Microsoft logic I guess. Not that I care what the manifest thing does anyways.

I've also figured out a way to parallelize the Dancing Links algorithm, so implementing that will be the main focus from now on, along with writing on the report. The end result will be that the matrices being sent to the worker nodes will be smaller than the original matrix. This will require some changes to the file format and also a smart way to merge the results back together. Hopefully I'll have a distributed computing sytem that actually works by the time the deadline rears its ugly head.

NOTE: This post has been imported from my old it's learning ePortfolio DECS blog.

The result is CMake2assistant, which you can grab from qt-apps.org. Quoting the README:

This tool parses CMake output to generate an HTML cross-referenced version of CMake commands and modules. It also generates a .dcf file which can be used to integrate the CMake documentation in Qt Assistant v3 or v4.

Since I know all you are looking for is screenshots, here are some pictures to feed your pixel hunger.

I am doing this on Gentoo linux, so your mileage may vary if you used a different distribution.

I am starting with http://gentoo-wiki.com/HOWTO_MinGW as a rough guide.

• # emerge -va sys-devel/crossdev
• # echo 'PORTDIR_OVERLAY="/usr/i686-mingw32/usr/portage /usr/local/portage $PORTDIR_OVERLAY"' >> /etc/make.conf
• create the directory /usr/i686-mingw32/usr/portage
• install the toolchain: # crossdev i686-mingw32

With Ubuntu/Debian you can simply install it using apt: "apt-get install mingw32". This will install the toolchain as i586-mingw32msvc-gcc to /usr/bin/ .emerge the packages you want to have as cross compiled programs or libraries.

Once you have installed ming32, it is easy to compile for linux:

#  i686-mingw32-gcc helloworld.cpp -o wintest.exe

Now the next step in the puxxle is to get cmake to compile for both OSes  each time make is run.

This is my experiment trying to do just that... Lets see if the Eclipse CDT is robust to do cross platform development!

Step 1: Install the Eclipse 3.3 SDK if you have not already done so. Make sure to get the CDT components. If you download the java sdk, you can add the CDT packages by adding the following plugin update site: http://download.eclipse.org/tools/cdt/releases/europa

Step 2: Install the cross platform make system, cmake. it's eclipse download site is:
http://cmakeed.sourceforge.net/updates/

Step 3: Create a C++ project in eclipse.

• Go to "New->C++ Project" Menu (or Go to "New->Hello World C++ Project" Menu if you are making an empty project and want to see some c++ code used by default)
• Select the MakeFile Project type, choose Other Toolchain and click Next
• Select the Advanced Settings Button
• Uncheck the Use Default Build Command
• Insert the following in the Build Command Text Field: make -C ${project_loc}/Build VERBOSE=1
• Under the "C/C++ Build" options, select "Settings".
• In the Right Side pane select the binary format for your system (Elf for linux).
• Click on the OK Button.
• Create a file in the project root named: CMakeLists.txt [todo: what are the contents of this file???]
• Open a terminal window
• cd to your project directory
• Create a build directory: mkdir Build
• Change directory to the Build dir: cd Build
• Run the command: ccmake ../
• Follow the ccmake instructions. when done, your project is ready.
• Refresh the eclipse project to show the new build directory.

Step 4: Create an eclipse run menu for cmake:

• Select the "Run->External Tools->Show External Tools Dialog..." menu.
• Create a new "Program" and call it Cmake.
• In the "Location" text field, type the absolute path to cmake (i.e /usr/local/bin/cmake or whatever path your system uses).
• In the "Working Directory" test field insert the following: "${project_loc}/Build" and in the Arguments section insert the following: "../".
• In the "Refresh" tab select The project containing the selected resources.
• In the "Common" tab check the "External Tools" selection.
• This will put a shortcut in the "Run" menu for you.
• Click the Apply Button and then run.
• CMake will now run on your project directory.

Step 5. Build the project using the command "Run -> External Tools -> cmake"

Next Up: Getting the project to generate both a windows exe and a linux executable.

see also: http://paraview.org/Wiki/CMake:Eclipse

Download the file cmake.tar.bz2

For any problem, contact me at gianco71[at]libero[dot]it