from:"Gonzalo Garramuño"



El 30/5/19 a las 21:36, Zan Lynx escribió:

RPM files are not cpio. They contain a cpio. Use rpm2cpio as a filter.


Thanks for that.  Using:

rpm2cpio mrViewer-v5.0.7-Linux-64.rpm | cpio -idmv

I can extract all the contents of the archive with no errors.

However, rpm -i bails out with a cpio: read error.  I don't know what to 
try next.  I have to wonder if the pre/post install scripts are the problem.


--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Cmake/Cpack creates a corrupt .rpm




El 30/5/19 a las 12:51, Gonzalo Garramuño escribió:

rpm -ql mrViewer-v5.0.6-Linux-64.rpm


If I run cpio -i < mrViewer-v5.0.6-Linux-64.rpm

I get a bunch of warnings of Incorrect numbers (and garbage) and Cannot 
make mknod: the multibyte or extended character is incomplete or 
invalid, and attention: 4390 bytes of garbage skipped and header is 
reversed and type of archive unknown and premature end of the archive.


--
Gonzalo Garramuño

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Cmake/Cpack creates a corrupt .rpm




El 30/5/19 a las 12:51, Gonzalo Garramuño escribió:

I have a CMakeLists.txt (extract) with the following commands:


SET(CPACK_GENERATOR DEB RPM TGZ )

# SET the installation directory.

SET(CPACK_SET_DESTDIR true) # Needed
SET(CPACK_INSTALL_PREFIX /usr/local/${mrViewerShortName})

SET(CPACK_RPM_PACKAGE_NAME mrViewer)
SET(CPACK_RPM_PACKAGE_RELOCATABLE false)


SET(  CPACK_RPM_POST_INSTALL_SCRIPT_FILE
    ${PROJECT_BINARY_DIR}/etc/Linux/install.sh)
SET( CPACK_RPM_POST_UNINSTALL_SCRIPT_FILE
    ${PROJECT_BINARY_DIR}/etc/Linux/uninstall.sh)


  SET(CPACK_PACKAGE_VENDOR "Film Aura, LLC")
  SET(CPACK_PACKAGE_VERSION_MAJOR ${VersionMajor})
  SET(CPACK_PACKAGE_VERSION_MINOR ${VersionMinor})
  SET(CPACK_PACKAGE_VERSION_PATCH ${VersionPatch})
  SET(CPACK_PACKAGE_VERSION "${SHORTVERSION}" )
  SET(CPACK_PACKAGE_FILE_NAME "${mrViewerPackageName}" )
  SET(CPACK_PACKAGE_CONTACT "ggarr...@gmail.com")
  SET(CPACK_PACKAGE_DESCRIPTION_SUMMARY
      "mrViewer provides professional flipbook, audio and video 
playback.")



#SET(CPACK_PACKAGE_INSTALL_REGISTRY_KEY ${mrViewerPackageName} )
SET(CPACK_RESOURCE_FILE_LICENSE 
${PROJECT_SOURCE_DIR}/../../docs/LICENSE.txt)


SET( CPACK_OUTPUT_CONFIG_FILE "${CMAKE_BINARY_DIR}/BundleConfig.cmake" )
include(CPack)

ADD_CUSTOM_TARGET( bundle
               COMMAND "${CMAKE_CPACK_COMMAND}"
               "-C" "$"
               "--config" "${CMAKE_BINARY_DIR}/BundleConfig.cmake"
               COMMENT "Running CPack. Please wait..."
               USES_TERMINAL
               DEPENDS translations )

This creates a valid DEB file but an invalid RPM which fails with:

Running transaction
Preparing : 1/1
Running scriptlet: mrViewer-5.0.5.20190517-1.x86_64 1/1
Installing : mrViewer-5.0.5.20190517-1.x86_64 1/1
Error unpacking rpm package mrViewer-5.0.5.20190517-1.x86_64
error: unpacking of archive failed: cpio: read

Verifying : mrViewer-5.0.5.20190517-1.x86_64 1/1

Failed:
mrViewer-5.0.5.20190517-1.x86_64

Error: Transaction failed


You can find the RPM file here:

https://sourceforge.net/projects/mrviewer/files/v5.0.6/mrViewer-v5.0.6-Linux-64.rpm/download 



If I use:

rpm -ql mrViewer-v5.0.6-Linux-64.rpm

all files are there.  However, when installing, the installer fails on 
reaching the lib directory of the rpm.


CMake/CPack used to build the rpm just fine some (long) versions ago 
with this same CMakeLists.txt.



Forgot to mention, I am using cmake 3.14.1.

--
Gonzalo Garramuño

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

[CMake] Cmake/Cpack creates a corrupt .rpm


I have a CMakeLists.txt (extract) with the following commands:


SET(CPACK_GENERATOR DEB RPM TGZ )

# SET the installation directory.

SET(CPACK_SET_DESTDIR true) # Needed
SET(CPACK_INSTALL_PREFIX /usr/local/${mrViewerShortName})

SET(CPACK_RPM_PACKAGE_NAME mrViewer)
SET(CPACK_RPM_PACKAGE_RELOCATABLE false)


SET(  CPACK_RPM_POST_INSTALL_SCRIPT_FILE
    ${PROJECT_BINARY_DIR}/etc/Linux/install.sh)
SET( CPACK_RPM_POST_UNINSTALL_SCRIPT_FILE
    ${PROJECT_BINARY_DIR}/etc/Linux/uninstall.sh)


  SET(CPACK_PACKAGE_VENDOR "Film Aura, LLC")
  SET(CPACK_PACKAGE_VERSION_MAJOR ${VersionMajor})
  SET(CPACK_PACKAGE_VERSION_MINOR ${VersionMinor})
  SET(CPACK_PACKAGE_VERSION_PATCH ${VersionPatch})
  SET(CPACK_PACKAGE_VERSION "${SHORTVERSION}" )
  SET(CPACK_PACKAGE_FILE_NAME "${mrViewerPackageName}" )
  SET(CPACK_PACKAGE_CONTACT "ggarr...@gmail.com")
  SET(CPACK_PACKAGE_DESCRIPTION_SUMMARY
      "mrViewer provides professional flipbook, audio and video playback.")


#SET(CPACK_PACKAGE_INSTALL_REGISTRY_KEY ${mrViewerPackageName} )
SET(CPACK_RESOURCE_FILE_LICENSE 
${PROJECT_SOURCE_DIR}/../../docs/LICENSE.txt)


SET( CPACK_OUTPUT_CONFIG_FILE "${CMAKE_BINARY_DIR}/BundleConfig.cmake" )
include(CPack)

ADD_CUSTOM_TARGET( bundle
               COMMAND "${CMAKE_CPACK_COMMAND}"
               "-C" "$"
               "--config" "${CMAKE_BINARY_DIR}/BundleConfig.cmake"
               COMMENT "Running CPack. Please wait..."
               USES_TERMINAL
               DEPENDS translations )

This creates a valid DEB file but an invalid RPM which fails with:

Running transaction
Preparing : 1/1
Running scriptlet: mrViewer-5.0.5.20190517-1.x86_64 1/1
Installing : mrViewer-5.0.5.20190517-1.x86_64 1/1
Error unpacking rpm package mrViewer-5.0.5.20190517-1.x86_64
error: unpacking of archive failed: cpio: read

Verifying : mrViewer-5.0.5.20190517-1.x86_64 1/1

Failed:
mrViewer-5.0.5.20190517-1.x86_64

Error: Transaction failed


You can find the RPM file here:

https://sourceforge.net/projects/mrviewer/files/v5.0.6/mrViewer-v5.0.6-Linux-64.rpm/download

If I use:

rpm -ql mrViewer-v5.0.6-Linux-64.rpm

all files are there.  However, when installing, the installer fails on 
reaching the lib directory of the rpm.


CMake/CPack used to build the rpm just fine some (long) versions ago 
with this same CMakeLists.txt.



--
Gonzalo Garramuño

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

[CMake] RC compilation failing

2019-04-09 Thread Gonzalo Garramuño

I had a resource.rc file and a resource.h file with just an ICON to 
provide the icon to my application.  However, since a week or so ago, RC 
refuses to compile it, giving the not very helpful message:


Microsoft (R) Windows (R) Resource Compiler Version 6.3.9600.17336
Copyright (C) Microsoft Corporation.  All rights reserved.

RC : fatal error RW1023: I/O error seeking in file

According to the MSDEV pages that means I don't have disk space, but 
that's not true.  I checked permissions too and that seemed okay too.


--
Gonzalo Garramuño

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Fwd: Re: Question about CMAKE_MODULE_PATH

2019-02-18 Thread Gonzalo Garramuño


El 18/2/19 a las 13:15, workbe...@gmx.at escribió:

Thank you, that did the trick. Now my other question is there a 
function in cmake that does abort the build/makefile generation 
process ? for example if i find out the system is not 64bit - is there 
something like quit() ?




message( FATAL_ERROR "your quit message" )

--
Gonzalo Garramuño

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Removing rpath paths

2018-10-28 Thread Gonzalo Garramuño




El 28/10/18 a las 18:32, Alexander Neundorf escribió:

well, then you do have some RPATH/RUNPATH somewhere ;-). As you say probably
in the libraries.
ld.so.conf could also contains additional search directories, but I doubt that
that's the case for you.


Yes, I found two libraries with rpath in them.  I used the commandline:

chrpath -d library

to remove it.  Now all is fine with the world.

--
Gonzalo Garramuño

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Removing rpath paths

2018-10-28 Thread Gonzalo Garramuño




El 28/10/18 a las 13:59, Alexander Neundorf escribió:

On 2018 M10 28, Sun 10:19:58 CET Gonzalo Garramuño wrote:
...

3) Why does running 'readelf -d myexecutable | grep RPATH' returns nothing

only grep for "PATH", then you also get the newer RUNPATH entry.

Alex

Thanks.  I tried it but it also shows nothing.  In principle I don't 
have any rpath.  However, in behavior I do.



--

Gonzalo Garramuño

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

[CMake] Removing rpath paths

2018-10-28 Thread Gonzalo Garramuño

This is probably something very simple, but I cannot find the answer.  I 
would like to remove all references to rpath and have my executable and 
libraries be controlled by LD_LIBRARY_PATH. According to the wiki, 
that's the default behavior.  However, I am finding it does not work so 
I set several options and nothing seems to work.  I think I might have 
stumbled into a bug in the libstdc++, but want to check:


Currently I have:

# use, i.e. don't skip the full RPATH for the build tree
SET(CMAKE_SKIP_BUILD_RPATH FALSE)

# when building, don't use the install RPATH already
# (but later on when installing)
SET(CMAKE_BUILD_WITH_INSTALL_RPATH FALSE)

# the RPATH to be used when installing
SET(CMAKE_INSTALL_RPATH "")

# don't add the automatically determined parts of the RPATH
# which point to directories outside the build tree to the install RPATH
SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH FALSE)

I compile my code on an Ubuntu 12.04.5 box for compatibility reasons.

When I install on an Ubuntu 16.04 which I also compile for, the error of 
my executable I get is the following:


/usr/local/mrViewer-v4.3.1-Linux-64/bin/mrViewer: relocation error: 
/usr/local/lib/libIlmCtl.so.1.5.0: symbol 
_ZTTNSt7__cxx1118basic_stringstreamIcSt11char_traitsIcESaIcEEE version 
GLIBCXX_3.4.21 not defined in file libstdc++.so.6 with link time reference


If I remove /usr/local/lib/libIlmCtl.so.1.5.0 from its location my 
executable works.  I am also shipping a version of libstdc++.so.6 with 
my executable, which might be a little weird.


The questions I would like some clarification are:

1) Do all the libs that my executable links to should have the rpath 
removed?


2) Why when I install an executable without rpath:

Set runtime path of "/usr/local/bin/exrmultiview" to ""

I can still run it even if LD_LIBRARY_PATH is unset?

3) Why does running 'readelf -d myexecutable | grep RPATH' returns nothing

--
Gonzalo Garramuño

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] /W1 and resource.rc files

2018-05-14 Thread Gonzalo Garramuño




El 13/05/2018 a las 21:24, Gonzalo Garramuño escribió:

I am running into trouble specifying the /W1 flag in add_definitions.

This was my problem.  I should have been using add_compile_options.

--
Gonzalo Garramuño

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

[CMake] /W1 and resource.rc files

2018-05-13 Thread Gonzalo Garramuño

I have a VC++ project which compiles with ninja.  I add all the sources 
and a rc file into a single executable by placing them in a variable.

I am running into trouble specifying the /W1 flag in add_definitions.
The flag gets passed onto RC and it fails its compilation.
Also, I get warnings of:
cl : Command line warning D9025 : overriding '/W3' with '/W1'
I am unsure what sets /W3.

Does anyone have a suggestion on how to work around the above, with the 
little fuss possible?


--
Gonzalo Garramuño

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

[CMake] /W1 and resource.rc files

2018-05-13 Thread Gonzalo Garramuño

I have a VC++ project which compiles with ninja.  I add all the sources 
and a rc file into a single executable by placing them in a variable.

I am running into trouble specifying the /W1 flag in add_definitions.
The flag gets passed onto RC and it fails its compilation.
Also, I get warnings of:
cl : Command line warning D9025 : overriding '/W3' with '/W1'
I am unsure what sets /W3.

--
Gonzalo Garramuño

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] VC2015 and Windows 7 compatibility

2017-09-20 Thread Gonzalo Garramuño




El 20/09/2017 a las 04:44, Elvis Stansvik escribió:

2017-09-20 7:53 GMT+02:00 Elvis Stansvik <elvis.stans...@orexplore.com>:

2017-09-19 23:22 GMT+02:00 Gonzalo Garramuño <ggarr...@gmail.com>:


El 19/09/2017 a las 15:19, J Decker escribió:

you can just install the runtime redistributuable for 2015...

https://www.microsoft.com/en-us/download/details.aspx?id=48234

Unfortunately, that does not have the required ms-api-win-core* DLLs.  It is
something that changed with v8.0 of windows.  Elvis solution seems like it
should work.  I am awaiting an answer from my beta testers.

What I forgot to say is that you of course need the Universal CRT DLLs
available somewhere on your build system where the CMake code behind
CMAKE_INSTALL_UCRT_LIBRARIES will find them.
Thanks, Elvis.  That helps.  I was able to get a Win64 build running on 
my Win7 (sans SP1) box once all the api-ms-win-core* packages were 
disted.   The Win32 build of my program cannot start with an 
api-ms-win-core-crt-*.dll error.


However since then I read that those api DLLs are not part of the 
Microsoft Runtime and as such cannot legally be disted and they 
shouldn't in any case for technical reasons (Microsoft might want to 
change them from version to version).


I am now trying to get a Windows7 SP1 box for myself to try further.

--
Gonzalo Garramuño

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] CPack: Create debian packge for each sub-project

2017-07-23 Thread Gonzalo Garramuño




El 23/07/17 a las 12:37, DKLind escribió:

I forgot, I also have a question about "make package". How do I build and
package just an individual sub-project. As expected, "make "
works to build, but there isn't a default target to package an individual
sub-project.
AFAIK, it is not possible. I would also like to know this for separate 
packager generators. How to call "make package" on just one package 
generator (like build just DEB and not RPM).


--
Gonzalo Garramuño

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] Boost moves to CMake

2017-07-18 Thread Gonzalo Garramuño


Just posted in the boost mailing list.  Congratulations to both teams!

--
Gonzalo Garramuño

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Help on first cmake project

2017-07-07 Thread Gonzalo Garramuño




El 07/07/17 a las 03:45, Florian Lindner escribió:

* Any other advises you want to give me?
I would advise you try to build out of source tree to keep the source 
clean.  Example:


$ mkdir build-linux64
$ cd build-linux64
$ cmake .. -G'Unix Makefiles'
$ make
$ make install

when done, you can then do:

$ cd ..
$ rm -rf build-linux64


Thanks for helping a beginner!

Florian

No problem.

--
Gonzalo Garramuño

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] .so link and cpack

2017-04-09 Thread Gonzalo Garramuño




El 09/04/17 a las 07:13, Eric Noulard escribió:

Hi Gonzalo,

You should be able to build Deb package including symlink without trouble.

Could you give the exact sequence of dpkg command which leads to the 
error you are speaking of?



$ dpkg -i mrViewer-v3.5.8-Linux-64.deb
(Leyendo la base de datos ... 309470 ficheros o directorios instalados 
actualmente.)

Preparando para desempaquetar mrViewer-v3.5.8-Linux-64.deb ...
Desempaquetando mrviewer (3.5.8) sobre (3.5.8) ...
dpkg: error al procesar el archivo mrViewer-v3.5.8-Linux-64.deb (--install):
 el tamaño del enlace simbólico 
'/usr/local/mrViewer-v3.5.8-Linux-64/lib/libACESclip.so' ha cambiado de 
48 a 20


Does it work ok if you uninstall the previously installed deb package 
first?



Yes.
Do you install the very same package twice or did you change somehow 
the package version?


I install a different revision of the same version of the package. So it 
unpacks v3.5.8 over v3.5.8


I think the problem is that I am installing it into an NTFS partition.  
I have both Ubuntu 12.04 and Ubuntu 16.04.1 and the problem appears on 
Ubuntu 16.04, which has its /usr/local pointing to a NTFS partition.

Sorry for the noise.
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] .so link and cpack

2017-04-08 Thread Gonzalo Garramuño

Currently, I have a project where I build a library and an executable 
that depends on the library.  Finally, I package a .deb package with cpack.


Now, my problem is that cpack packs the symbolic link of my library and 
that creates problems with the deb installer ( dpkg -i ) whenever I try 
to install the same version of my program twice. The error I get is that 
the symbolic link changed value from 20 to 42 (or something like that).


I tried removing the symbolic link previous to packaging, but then I get 
cpack erroring out with:


CMake Error at 
/media/gga/Datos/code/applications/mrViewer/BUILD/Linux-3.13.0-108-generic-64/Release/tmp/libACESclip/cmake_install.cmake:47 
(file):

  file INSTALL cannot find
"/media/gga/Datos/code/applications/mrViewer/BUILD/Linux-3.13.0-108-generic-64/Release/lib/libACESclip.so".

Following a post on stackoverflow, I also tried using NAMELINK_SKIP on 
the library, like:



set_target_properties( ACESclip
  PROPERTIES
  SOVERSION ${SOVERSION})

install( TARGETS ACESclip
  RUNTIME DESTINATION bin
  LIBRARY DESTINATION lib
  ARCHIVE DESTINATION lib
  NAMELINK_SKIP )

But then the executable:

ADD_EXECUTABLE( mrViewer WIN32 ${SOURCES} )
TARGET_LINK_LIBRARIES( mrViewer ${LIBRARIES} ACESclip )

would not find my library and would error out.

Therefore, I turn to the list for help.  How do I prevent cpack from 
packaging symbolic links (a feature which is kind of wrong at least for 
.deb files)?  Or how do I make my executable use the library without 
symlinks?


Thanks in advance.


--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Desktop icon not safe (missing +x ) on cmake deb file

2017-03-19 Thread Gonzalo Garramuño




El 19/03/2017 a las 15:13, Gonzalo Garramuño escribió:

Hi,

I had a program which I compile with cmake.  This program was on an 
NTFS partition with permissions: defaults.  This meant all files were 
owned by root with 777 permissions.   This worked fine but it was not 
secure and created problems with the postrm/posinst scripts.


Recently I tried changing my fstab to mount the partition with user 
and permissions,like:


UUID=98222A3D222A20AC  /media/gga/Datos ntfs-3g 
auto,users,permissions,exec 0 0


Now, when I package my application into a deb file, it works.  I get:

-rw-r--r-- 1 gga gga 24M mar 19 14:55 mrViewer-v3.5.4-Linux-64.deb


I figured it out.  For reference, I had to change the fstab file to:

UUID=98222A3D222A20AC  /media/gga/Datos ntfs-3g 
auto,users,permissions,exec,uid=1000,gid=1000,umask=022 0 0


--
Gonzalo Garramuño

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] Desktop icon not safe (missing +x ) on cmake deb file

2017-03-19 Thread Gonzalo Garramuño


Hi,

I had a program which I compile with cmake.  This program was on an NTFS 
partition with permissions: defaults.  This meant all files were owned 
by root with 777 permissions.   This worked fine but it was not secure 
and created problems with the postrm/posinst scripts.


Recently I tried changing my fstab to mount the partition with user and 
permissions,like:


UUID=98222A3D222A20AC  /media/gga/Datos ntfs-3g 
auto,users,permissions,exec 0 0


Now, when I package my application into a deb file, it works.  I get:

-rw-r--r-- 1 gga gga 24M mar 19 14:55 mrViewer-v3.5.4-Linux-64.deb

However upon installation of the deb file under root, I get an icon in 
the desktop that is not executable. The desktop file that gets created 
from a desktop.in config file, which has permissions like:


-rwxrwxrwx 1 gga root 1,2K feb 21 12:14 mrViewer.desktop.in

and the resulting .desktop file has permissions like:

-rwxrwxrwx 1 gga root 1,2K mar 14 09:36 mrViewer-v3.5.4.desktop

So it should be executable and it should get installed with same 
permissions.   However, this does not work.


I am at a loss on what to try.  Any help is appreciated.

--
Gonzalo Garramuño

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Forcing linking compatability to old libc / libstdc++ (Linux)

2017-01-26 Thread Gonzalo Garramuño




El 26/01/2017 a las 18:35, Michael Ellery escribió:

In what way is the stdlib incompatible? Does it have bugs, or is this more a 
matter of cpp standard support?
I should have been more clear.  Sorry.   The incompatabilities happen at 
linker time, with complaints such as:


exrstdattr: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found 
(required by exrstdattr )
exrstdattr: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found 
(required by /usr/local/mrViewer/lib/libIlmImf-2_2.so.22 )


If I copy the latest libstdc++.so.6 I have on Ubuntu, I get:

exrstdattr: /lib64/libc.so.6: version `GLIBC_2.18' not found (required 
by /usr/local/mrViewer/lib/libstdc++.so.6 )


--
Gonzalo Garramuño

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] Forcing linking compatability to old libc / libstdc++ (Linux)

2017-01-26 Thread Gonzalo Garramuño

I currently own an Ubuntu Xenial 14.04.1 LTS box in which I do all my 
work.I distribute a binary image viewer.   However, recently one of 
my users tried to run the viewer on a CentOS 7 distro and found out that 
that distro libc and libstdc++ are older and incompatible.


I would like to compile my program targeting the older libc and 
libstdc++.  Those files come with symbol version and visibility. Is 
there an easy way to do that other than copying the old libraries?


Any help or hint is appreciated.

--
Gonzalo Garramuño

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] install() rename with version string

2017-01-19 Thread Gonzalo Garramuño




El 19/01/17 a las 05:30, Wagner Martin escribió:


However, CMake needs to include version.cmake at first CMake run time, 
which is not possible because it’s a generated file.


Is there any other way to do the rename?



You will need to do the install as another target/command.  For example:

add_custom_command( TARGET version
POST_BUILD
COMMAND ${CMAKE_COMMAND} -D 
VERSION=${version_string}

-P install_commands.cmake
USES_TERMINAL )

--
Gonzalo Garramuño

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Custom command on cpack target

2017-01-14 Thread Gonzalo Garramuño


El 10/01/17 a las 17:34, Gonzalo Garramuño escribió:


I would like to run a custom command on the zip file generated by 
cpack.   The idea is that I want to calculate its sha256 checksum.  
Unfortunately it seems the zip file cannot be a target in a 
CMakeLists.txt file or I'm doing something wrong.


Can someone give me a hand?


To answer my own question and for others that might want to do the same:

# Cmake only adds the default package target if a package config file
# named CPackConfig.cmake exists in the outermost binary build directory.
# By forcing the CPack module to generate the package file under a
# different name, we prevent the "target" path from being generated.
SET( CPACK_OUTPUT_CONFIG_FILE "${CMAKE_BINARY_DIR}/BundleConfig.cmake" )
include(CPack)

ADD_CUSTOM_TARGET( bundle
   COMMAND "${CMAKE_CPACK_COMMAND}"
"-C" "$"
   "--config" "${CMAKE_BINARY_DIR}/BundleConfig.cmake"
   COMMENT "Running CPack. Please wait..."
   DEPENDS ${PROJECT_NAME})

IF (WIN32)
   ADD_CUSTOM_COMMAND( TARGET bundle
  POST_BUILD
  COMMAND ${CMAKE_COMMAND} -D 
CMAKE_SYSTEM_NAME=${CMAKE_SYSTEM_NAME} -D VERSION=${VERSION} "-P" 
"${CMAKE_CURRENT_SOURCE_DIR}/../../chocolatey/mrViewer/CMakeLists.txt"

   WORKING_DIRECTORY "${CMAKE_CURRENT_SOURCE_DIR}"
 )
ENDIF( WIN32 )

This works in that instead of calling make/ninja package you call 
make/ninja bundle.


--
Gonzalo Garramuño

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] Custom command on cpack target

2017-01-10 Thread Gonzalo Garramuño



I would like to run a custom command on the zip file generated by 
cpack.   The idea is that I want to calculate its sha256 checksum.  
Unfortunately it seems the zip file cannot be a target in a 
CMakeLists.txt file or I'm doing something wrong.


Can someone give me a hand?


--
Gonzalo Garramuño

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] Chocolatey? (Windows)

2017-01-10 Thread Gonzalo Garramuño

I was wondering if anyone was familiar with Chocolatey and whether there 
are plans to add support for it in cmake/cpack.


For those that don't know, Chocolatey is a small Windows' utility 
similar to Debian's apt-get.  It allows simple management of packages 
(binaries mainly).


--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Off-topic? Winmm linking/running problems

2016-06-08 Thread Gonzalo Garramuño


On 08/06/2016 12:11 p.m., Gonzalo Garramuño wrote:
I have a multiplatform viewer and recently I started to experience 
some very weird behavior.
Found the problem being the volume control not being 32bits.   Sorry for 
the noise.


--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] CMake v3.6.0 rc1

2016-06-08 Thread Gonzalo Garramuño

I tried v3.6.0 rc1 but it fails on linking with a message about unknown 
symbols when doing cmake -E vs_link_dll on a windows library.  It seems 
not to recognize the symbols in, for example, tinyxml2.


The same code works just fine under cmake v3.5.2.
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] Off-topic? Winmm linking/running problems

2016-06-08 Thread Gonzalo Garramuño

I have a multiplatform viewer and recently I started to experience some 
very weird behavior.
I am using the latest cmake 3.5.3 rc1 and the latest released ninja 
(1.7), albeit the problem appears with NMake Makefiles too.
The viewer links against winmm.dll, the windows multimedia library for 
audio.  I am using ffmpeg to decode the audio with /OPT:NOREF.


My problem is that the win64 version of my program, while testing in the 
sandbox, plays all audio in mono.

The win32 version of my program (same code) works fine from the sandbox.
Also, when I move the win64 version of the program (doing ninja install, 
package install or even just a plain cp to a new tree), the same win64 
version of my program plays audio (stereo, 5:1) just fine.
The linux amd64 version of my program also plays audio just fine without 
installing.

All the code lies in an NTFS partition.

I am at a loss as to what might the problem be.  I am pretty sure all 
variables are initialized properly and that there's no memory issue, but 
you never know.  I have no spaces in the paths.  It is not a driver 
issue as some other user reported mono playback too.  I was wondering if 
someone has experienced anything like this and how to debug it.


--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] How to run an install command as administrator?

2016-05-28 Thread Gonzalo Garramuño


On 26/05/2016 01:16 p.m., Juan Dent wrote:


Hi,

I have a simple CMakeLists.txt that tries to install at a place in the 
drive that requires administrator privileges. How can I make that 
install command to run as administrator, is there a way in CMake?



If you are on Linux or Mac, it is easy.  Just do:

$ sudo make install

If you are on Windows, create a .bat file with the cmake command you 
want to run and then RMB on it and select Run As Administrator.


-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] CPACK_NSIS_EXTRA_INSTALL_COMMANDS before install

2016-05-28 Thread Gonzalo Garramuño


Hi,

I am using CPACK_NSIS_EXTRA_INSTALL_COMMANDS to create a new page where 
the user can select file associations (using the full syntax of NSIS).  
My problem is that the page gets shown after the install is done.  I 
would like to have a variable which puts the NSIS commands before the 
install.

Is there any way or variable to achieve that?

gets shown after the install
   is done.  I would like to have a variable which puts the NSIS
   commands before the install.
   Is there any way or variable to achieve that?
   
 

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] [ANNOUNCE] CMake 3.4.3 available for download

2016-01-25 Thread Gonzalo Garramuño


On 25/01/2016 04:36 p.m., Robert Maynard wrote:

We are pleased to announce that CMake 3.4.3 is now available for download.

Please use the latest release from our download page:
   https://cmake.org/download/


Brad,

Does this one have the fix for the FLTK_WRAP_UI?

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Internal error bug in v3.4.2.

2016-01-21 Thread Gonzalo Garramuño


On 21/01/2016 03:47 p.m., Brad King wrote:

On 01/21/2016 11:00 AM, Gonzalo wrote:

Find attached the mrViewer/src/CMakeList.txt file that still fails.

Thanks.  From that I was able to reproduce it in a small test case
with CMake 3.4.  It appears that the problem has been fixed since
then in 'master'.  I've added a test case to keep it working:
Thank you very much for the prompt resolution.   I'll check the master 
repo and shall confirm if all is fixed.


Once again,
thank you very mucho :D

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] ninja under windows

2015-08-03 Thread Gonzalo Garramuño


I compiled Ninja on cygwin from git.  That now works fine it seems.
I am trying to compile for msvc.  However, when cmake runs, I get:

[1/123] Building CXX object 
'libACESclip\CMakeFiles\ACESclip.dir\src\ACESclipWriter.cpp.obj'ninja: 
fatal: unknown deps type 'msvc'


$ ninja --version
1.6.0.git

Is compiling under the microsoft compiler not an option for ninja files 
( I can compile with NMake Makefiles just fine in the same project ).

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] NSIS startup menu and icons

2015-01-10 Thread Gonzalo Garramuño

I have created an NSIS section for my CMakeLists.txt and I am trying to 
pack and install my application (mrViewer).
The package builds correctly and runs just fine, but the mrViewer icon 
is missing in desktop and in the menu entry and the startup menu has a 
mrViewer entry that leads nowhere instead of running my program.
I am sure it is a path issue somewhere but I don't know how to debug it, 
so I am asking for help here.


I have the following:

add_executable( mrViewer WIN32 ${SOURCES} )
target_link_libraries( mrViewer ${LIBRARIES} )


install( TARGETS mrViewer
  RUNTIME DESTINATION ${mrViewerPackageName}/bin
  LIBRARY DESTINATION ${mrViewerPackageName}/lib )

  set(CPACK_NSIS_MUI_ICON 
${PROJECT_SOURCE_DIR}/mrViewer/src/icons/viewer.ico)
  set(CPACK_NSIS_MUI_UNICON 
${PROJECT_SOURCE_DIR}/mrViewer/src/icons/viewer.ico)


  if (CMAKE_BUILD_ARCH EQUAL 32)

set(CPACK_NSIS_INSTALL_ROOT $PROGRAMFILES)

  elseif (CMAKE_BUILD_ARCH EQUAL 64)

set(CPACK_NSIS_INSTALL_ROOT $PROGRAMFILES64)

  endif (CMAKE_BUILD_ARCH EQUAL 32)

  SET( CPACK_NSIS_MODIFY_PATH ON )
  SET( CPACK_CREATE_DESKTOP_LINKS ON )
  set(CPACK_PACKAGE_INSTALL_DIRECTORY ${mrViewerPackageName})

set(CPACK_PACKAGE_VERSION_MAJOR ${mrViewerVersionMajor})
set(CPACK_PACKAGE_VERSION_MINOR ${mrViewerVersionMinor})
set(CPACK_PACKAGE_VERSION_PATCH ${mrViewerVersionPatch})
set(CPACK_PACKAGE_CONTACT http://mrviewer.sourceforge.net)
# set(CPACK_PACKAGE_DESCRIPTION_FILE ${PROJECT_SOURCE_DIR}/README.txt)
set(CPACK_PACKAGE_DESCRIPTION_SUMMARY
mrViewer provides professional flipbook, audio and video playback.)

set(CPACK_PACKAGE_EXECUTABLES mrViewer mrViewer )
set(CPACK_PACKAGE_INSTALL_REGISTRY_KEY ${mrViewerPackageName} )
set(CPACK_RESOURCE_FILE_LICENSE ${PROJECT_SOURCE_DIR}/LICENSE.txt)

set(CPACK_PACKAGE_FILE_NAME ${mrViewerPackageName})
set(CPACK_NSIS_INSTALLED_ICON_NAME binmrViewer.exe)

And find attached the resulting project.nsi file.
; CPack install script designed for a nmake build

;
; You must define these values

  !define VERSION 0.1.1
  !define PATCH  1
  !define INST_DIR 
F:/code/applications/mrViewer/BUILD/Windows-6.1-64/Release/tmp/_CPack_Packages/win64/NSIS/mrViewer-2.6.7-Windows-64

;
;Variables

  Var MUI_TEMP
  Var STARTMENU_FOLDER
  Var SV_ALLUSERS
  Var START_MENU
  Var DO_NOT_ADD_TO_PATH
  Var ADD_TO_PATH_ALL_USERS
  Var ADD_TO_PATH_CURRENT_USER
  Var INSTALL_DESKTOP
  Var IS_DEFAULT_INSTALLDIR
;
;Include Modern UI

  !include MUI.nsh

  ;Default installation folder
  InstallDir $PROGRAMFILES64\mrViewer-2.6.7-Windows-64

;
;General

  ;Name and file
  Name mrViewer-2.6.7-Windows-64
  OutFile 
F:/code/applications/mrViewer/BUILD/Windows-6.1-64/Release/tmp/_CPack_Packages/win64/NSIS/mrViewer-2.6.7-Windows-64.exe

  ;Set compression
  SetCompressor lzma

  ;Require administrator access
  RequestExecutionLevel admin



  !include Sections.nsh

;--- Component support macros: ---
; The code for the add/remove functionality is from:
;   http://nsis.sourceforge.net/Add/Remove_Functionality
; It has been modified slightly and extended to provide
; inter-component dependencies.
Var AR_SecFlags
Var AR_RegFlags


; Loads the selected flag for the section named SecName into the
; variable VarName.
!macro LoadSectionSelectedIntoVar SecName VarName
 SectionGetFlags ${${SecName}} $${VarName}
 IntOp $${VarName} $${VarName}  ${SF_SELECTED}  ;Turn off all other bits
!macroend

; Loads the value of a variable... can we get around this?
!macro LoadVar VarName
  IntOp $R0 0 + $${VarName}
!macroend

; Sets the value of a variable
!macro StoreVar VarName IntValue
  IntOp $${VarName} 0 + ${IntValue}
!macroend

!macro InitSection SecName
  ;  This macro reads component installed flag from the registry and
  ;changes checked state of the section on the components page.
  ;Input: section index constant name specified in Section command.

  ClearErrors
  ;Reading component status from registry
  ReadRegDWORD $AR_RegFlags HKLM 
Software\Microsoft\Windows\CurrentVersion\Uninstall\mrViewer-2.6.7-Windows-64\Components\${SecName}
 Installed
  IfErrors default_${SecName}
;Status will stay default if registry value not found
;(component was never installed)
  IntOp $AR_RegFlags $AR_RegFlags  ${SF_SELECTED} ;Turn off all other bits
  SectionGetFlags ${${SecName}} $AR_SecFlags  ;Reading default section flags
  IntOp $AR_SecFlags $AR_SecFlags  0xFFFE  ;Turn lowest (enabled) bit off
  IntOp $AR_SecFlags $AR_RegFlags | $AR_SecFlags  ;Change lowest bit

  ; Note whether this component was installed before
  !insertmacro StoreVar ${SecName}_was_installed $AR_RegFlags
  IntOp $R0 $AR_RegFlags  $AR_RegFlags

  ;Writing modified flags
  SectionSetFlags ${${SecName}} $AR_SecFlags

 default_${SecName}:
 !insertmacro LoadSectionSelectedIntoVar ${SecName} ${SecName}_selected
!macroend

!macro FinishSection SecName
  ;  This macro

[CMake] NSIS builder creating invalid exe

2015-01-09 Thread Gonzalo Garramuño

I updated my CMakeLists.txt to create an NSIS installer under a Nmake 
Makefile.

The packaging works without errors when run with 'nmake package'.

However, the resulting exe file when run, returns:
Bad file number.

The problem happens on both builds for win32 and win64.
The NSIS installer is 3.0a1 and cmake v3.0.1.

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Creating an installer using cpack

2015-01-09 Thread Gonzalo Garramuño


On 09/01/2015 05:55 p.m., J Decker wrote:



the symlinks already exist in the source directory (it sounds like) 
the problem is they're not being packaged/extracted right...
Correct.  I changed my symlink script with one that copies the libraries 
and all problems are gone.

Now I am tackling NSIS problems on Windows.

Thanks to all for your help.
Gonzalo

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] EXECUTABLE_OUTPUT_PATH vs CMAKE_RUNTIME_OUTPUT_DIRECTORY


Alexander Neundorf wrote:


Brad just documented this a few days ago:
http://www.cmake.org/pipermail/cmake-commits/2008-February/00.html



This is a pretty horrible and drastic change with no heads up.  Why was 
the variable name change even needed?  I have tons of code already coded 
that depends on those variables.



--
Gonzalo Garramuño
[EMAIL PROTECTED]

AMD4400 - ASUS48N-E
GeForce7300GT
Xubuntu Gutsy
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] [Spam] Re: EXECUTABLE_OUTPUT_PATH vs CMAKE_RUNTIME_OUTPUT_DIRECTORY


Andreas Pakulat wrote:

On 04.03.08 10:51:10, Gonzalo Garramuño wrote:

Alexander Neundorf wrote:

Brad just documented this a few days ago:
http://www.cmake.org/pipermail/cmake-commits/2008-February/00.html

This is a pretty horrible and drastic change with no heads up.  Why was the 
variable name change even needed?  I have tons of code already coded that 
depends on those variables.


So? There's nowhere stated that those variables go away, they are just
deprecated and you shouldn't use them. 


Well...  That's what deprecated is.  It means the variables may go away 
or not work properly anymore in either a current or future cmake 
version.  It also means they are no longer supported (bugs, etc).



Apart from that that only applies
to CMake 2.6, everythings fine if your projects require CMake 2.4.



Well, I'm using cmake 2.5 from SVN.  I'm trying to understand what does 
the name change even accomplish?  If the renaming had been to make the 
variables prefixed with CMAKE_*, I would understand it as a 
consolidation with other cmake variables.  But as is, I don't get the 
need for the change at all.



Also, from an API perspective, I find this hilarious:

ARCHIVE_OUTPUT_DIRECTORY, LIBRARY_OUTPUT_PATH, and RUNTIME_OUTPUT_DIRECTORY

Either name them all DIRECTORY or PATH to be consistent.


--
Gonzalo Garramuño
[EMAIL PROTECTED]

AMD4400 - ASUS48N-E
GeForce7300GT
Xubuntu Gutsy
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] cmake community site


Mike Jackson wrote:


Also, what happens when you stop being a student with lots of time to 
keep the site going?


That's easy.  If he did a good job, he gets hired by Kitware :)

--
Gonzalo Garramuño
[EMAIL PROTECTED]

AMD4400 - ASUS48N-E
GeForce7300GT
Xubuntu Gutsy
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] [Spam] Brandon Van Every


Bill Hoffman wrote:
This is a difficult decision for me.   I have never been forced into a 
situation like this.  However, Brandon's posts to this list have been 
disruptive to the community and myself.  I have therefore come to the 
conclusion that Brandon needs to be kicked off the list.


I hope we can put this issue behind us soon, and move forward with the 
development of the CMake build system.




Bill, the guy already sent a public email with personal stuff.  He will 
have enough punishment with anyone being able to google for it.


For anyone that is tired of him, my suggestion is: email filter or 
killfile.  That suggestion goes to Brandon too (to filter Sebastian or 
whatever was his name).   End of story.


--

The reason why I would vote to keep Brandon is, that, unlike that guy, I 
found two or three things he did that I found/find useful on this list 
(and why I sometimes answer his posts).


a) He surfs the web... a lot.  Thanks to him I found out about premake 
and buildr (both of which I had no clue existed).  I have yet to find 
something he linked to truly useful, but there's a chance he'll stumble 
upon it, even if by sheer chance.  He certainly found cmake before I did.


b) In the past, he did raise some valid issues with cmake.  He was the 
first to notice bad mingw/msys support, for example.  He was first to 
point out regexp issues.  And since he seems to only code in cmake, he 
seems to find a lot of (minor) bugs.


c) I actually took the time to look at his mozilla translator (what can 
I say? boring day).  It is not great or something I would use.  But it 
is certainly above totally clueless levels.  I would rather keep him 
around and help him with his code (and for those that are better than 
myself at it, with his people skills too).



--
Gonzalo Garramuño
[EMAIL PROTECTED]

AMD4400 - ASUS48N-E
GeForce7300GT
Xubuntu Gutsy
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Re: Raven, Antwrap, Buildr

2008-03-03 Thread Gonzalo Garramuño

 for actual coding the core of the system.



P.S.  BTW, rake is something like a 200 line script only, so it is 
extremely bare-bones.



--
Gonzalo Garramuño
[EMAIL PROTECTED]

AMD4400 - ASUS48N-E
GeForce7300GT
Xubuntu Gutsy
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Re: Changing MD - MT (+patch for free toolkit)

2008-02-19 Thread Gonzalo Garramuño


Mathieu Malaterre wrote:

On Feb 19, 2008 5:43 AM, Gonzalo Garramuño [EMAIL PROTECTED] wrote:

Mathieu Malaterre wrote:

Ok this was yet-another-weird-dll thingy, one cannot do:

class GDCM_EXPORT String : std::string { ... }


Please, learn a little bit more about C++.


Oh thank you ! I'll take your advice right away, mister expert. So
could you please let me know why *in my particular case* this is
wrong:
1. I did not add any data member
2. I did not overload the dstor



GDCM_EXPORT tells me you are using this in a library.

The reason this is wrong is this.  Say you write a function to get a 
exension of a filename as uppercase:


GDCM_EXPORT MyString get_extension( const MyString b )
{
   MyString ext = b.to_upper();
   // etc... do some other stuff like find '.' and substr
   return ext;
}

Now... this will work.  But now func() can only be used with your 
particular MyString class.  However, if you had done:


namespace str {
   // to_upper implementation not shown
   GDCM_EXPORT std::string to_upper( const std::string b );

   GDCM_EXPORT std::string get_extension( const std::string b )
   {
 std::string ext = to_upper( b );
 // etc... do some other stuff like find '.' and substr
 return ext;
   }
}


With this, the code for both to_upper() and get_extension() can be 
safely be reused and works for *all* std::string objects.  You don't 
force people to use your own string library.  This makes your library 
more attractive and easier to reuse in other code.


Even, if you did not do 1 or 2, you might have done 3:
3. Yo might have overloaded (replaced) a string function.

class MyString : public std::string
{
public:
   // silly example, but same applies to add, operator, etc.
   size_type size() { return std::string::size() + 1; }
};

int main()
{
 MyString* s = new MyString;
 std::string* c = static_cast std::string* ( s ); // correct
 std::cerr  c-size()  std::endl;   // which size() gets called?
// not yours,
// but the one in std::string
 return 0;
}

This example for 3) is very simple and obvious but in big programs this 
issue may be more confusing as the distintion of what a pointer really 
points to becomes more blurry.


If you have only added non-conflicting functions in MyString to 
std::string, what you have is safe but potentially not so beneficial. 
You might either do as I showed and place your additional functions in a 
namespace and keep using std::string everywhere (which makes your 
library nice to use and probably popular) or create your own string 
class, without deriving anything (and yes, you do need to create a lot 
of code for doing a good string class -- it is C++ after all), or create 
a proxy string class thru containment of std::string (which is like 
creating your own string class from scratch, but a tad simpler):


class MyString
{
std::string str;

public:
 typedef std::string::size_type size_type;
 // other typedefs similar to std::string...

public:
 MyString() {}
 MyString(const MyString b) : str(b.str) {}
 MyString(const std::string b) : str(b)  {}

// auto cast to string - optional (only if lazy, may not be wanted)
operator std::string() const { return str; }

// dispatch size function
inline size_type size() const { return str.size(); }

// my functions - not shown
void to_upper();

//  dispatch others, etc...
// also remember to add operator=(const std::string b)
};

This avoids you having to actually write your (potentially buggy) code 
to the string functions, as you just dispatch the operations to the 
std::string inside your class.  And the operator to std::string() and 
copy constructor of std::string allows your class to interact with 
std::string functions and elements rather seamlessly.  It is still 
verbose, but not *THAT* much.  And the code is probably safer to use 
through pointers and easy to extend without conflicts.




Please do not copy some random comment found on the internet and
instead comment on my particular implementation with the following 1
and 2 restrictions. Thanks.



It is not some random comment.  It is good design advice that sadly 
applies to all C++ STL classes.


For more information, refer to a good C++ book. IIRCC, Scott Meyer's 
Effective STL and Effective C++, covers this and other problems with all 
the pitfalls in a very thorough fashion.



--
Gonzalo Garramuño
[EMAIL PROTECTED]

AMD4400 - ASUS48N-E
GeForce7300GT
Xubuntu Gutsy
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Re: Changing MD - MT (+patch for free toolkit)

2008-02-18 Thread Gonzalo Garramuño


Mathieu Malaterre wrote:

Ok this was yet-another-weird-dll thingy, one cannot do:

class GDCM_EXPORT String : std::string { ... }



Please, learn a little bit more about C++.  You should never inherit 
from std::string (or any std::* container) as their functions or 
destructor are not virtual.  That can (and will) spell disaster for 
anyone else trying to use your library/functions or even for yourself if 
you go through pointers or references.


--
Gonzalo Garramuño
[EMAIL PROTECTED]

AMD4400 - ASUS48N-E
GeForce7300GT
Xubuntu Gutsy
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] add_custom_command as target

2008-01-17 Thread Gonzalo Garramuño



Cmake provides add_custom_target, but that creates a target that gets 
run either always (ALL) or manually by running make target.


Cmake also provides an add_custom_command that tracks file dependencies 
and gets run when a dependency changes.  However, add_custom_command 
assumes the files are always intermediate files (ie. not targets) and 
for the command to actually appear in the Makefile, the output of the 
command has to have been added to add_executable or similar.


Is there a way to create an add_custom_target that tracks dependencies? 
 Or an add_custom_command that will act as a target (without needlessly 
being added to add_executable, etc).


Basically, I'm trying to have a macro that compiles NVidia's .cg files 
to profile shaders and as such the shaders are targets that depend on 
the cg files.


--
Gonzalo Garramuño
[EMAIL PROTECTED]

AMD4400 - ASUS48N-E
GeForce7300GT
Xubuntu Gutsy
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] add_custom_command as target

2008-01-17 Thread Gonzalo Garramuño


Brandon Van Every wrote:


Admittedly this is inelegant, but it works.  I have no idea how much
work it would be to remove the distinction between file level and
target level dependencies.



It isn't inelegant, but quite logical.  It probably should be kept as 
is, as it allows easily adding multiple dependencies to a single target.


I thought of trying that as a last resort but by then I had more or less 
given up.


That feature is, however, undocumented.  Neither of the add_custom_* nor 
the wiki has any mention of this or the possibility of add_custom_target 
being able to take a custom command.


--
Gonzalo Garramuño
[EMAIL PROTECTED]

AMD4400 - ASUS48N-E
GeForce7300GT
Xubuntu Gutsy
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [Spam] Re: [CMake] Re: Migration to subversion

2008-01-04 Thread Gonzalo Garramuño


Alan W. Irwin wrote:

developers, but most software projects (such as CMake) will never have more
than a handful of active developers


cmake already has about 10-20 or so developers (if you consider all the 
.cmake module contributions).  People with commit access, however, are 
much fewer right now.




I assume that does not rule out git or Mercurial.  For example, from the
git-svn crash course at http://git.or.cz/course/svn.html, it appears that
git has the capability to use a centralized repository (the so-called bare
repository), and I presume that is the case for Mercurial as well.


Not really. Both git and Mercurial are always distributed.  You can have 
one official repository but you cannot prevent people from cloning it.



However, I admit to having no development experience with git or Mercurial.
Is there anything compelling (e.g., fewer bugs, better documentation, more
useful features aside from distributed?) about either over svn for 
projects like CMake that use a centralized repo?




See Linus presentation at google (available on youtube).  But basically, 
with git you get:


* Faster and smaller repositories.  A git repository will often be 1/3rd 
of an equivalent cvs or svn one.
* git guarantees that what you put in the repository is what you get 
out.  All commits are SHA1 verified.  CVS and SVN have no verification. 
 If disk corruption happens or a malicious user fakes a file or screws 
up, say, the ,v files, you can get garbage out without anyone noticing.
* git offers two apis (one for high level user access and one for low 
level admin/script access similar to using tricks in cvs like hacking 
the ,v files).
* Branches and merging are native to the repository.  Both can be done 
in linear time (and probably) with much less chance of conflicts.
* Distributed.  You can work with the repository without being connected 
(on a plane or laptop, for example) and then merge later.
* Distributed allows you to much more easily mix and match from several 
repositories of trusted persons, to create your own flavor of code.  For 
example, Linus is not an expert in networking, but he can easily fetch 
and merge network changes from other developers that are, once they 
verified the code (thus, reducing the amount of work *he* has to do on 
things he is not really an expert on).  A central repository makes it 
much more easy for the changes of the two developers to overlap or screw 
up the build of the other person while developing.  Or the developer 
just has to never commit, until all your tests pass and your changes 
are done.
* git offers bisect options in linear time.  It becomes trivial to find 
a line commit that screwed up something.  There's nothing like that on 
CVS or SVN, where it has to be done manually.  And even then, it is not 
linear.
* git patches can be created to be easy to email for those that have no 
write access.
* git has proven scalability (for both git and the kernel, probably some 
of the largest per day/month commit base of any known projects).


With Mercurial you get the same except faster and smaller and only a 
single api.  It is at least 40% slower than git in my (short) 
experience.  Monotone offers better verification but much, much slower 
performance.


In summary, once you use git, if you are like me, you'll realize that 
you've been doing source version control wrong all these years *sigh*.


--
Gonzalo Garramuño
[EMAIL PROTECTED]

AMD4400 - ASUS48N-E
GeForce7300GT
Xubuntu Gutsy
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Re: Migration to subversion

2008-01-04 Thread Gonzalo Garramuño


James Mansion wrote:

Gonzalo Garramuño wrote:
In summary, once you use git, if you are like me, you'll realize that 
you've been doing source version control wrong all these years *sigh*.



Does git work on Win32?



Yes, but not as well as on Linux.  There's two ports of it.

The cygwin port which should be more or less in sync with Linux but 
works very slow.  It is also probably not that well suited for windows 
projects, as I believe no CR/LF conversion is done.


The MinGW port which is much faster and already pretty functional (look 
for msysgit, IIRC).  It also handles CR/LF conversions.  This is likely 
the one you want to try.  Some advanced functionality may still be 
missing as it is not a complete project yet.



--
Gonzalo Garramuño
[EMAIL PROTECTED]

AMD4400 - ASUS48N-E
GeForce7300GT
Xubuntu Gutsy
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] mingw32 linker line exceeds win32 limitations

2008-01-03 Thread Gonzalo Garramuño


Brad King wrote:


CMake uses a link script approach to avoid placing the entire link
line in the makefile.  It is enabled on certain generators (including
MinGW) and used for linking libraries but has not been yet needed for
executables.  Is the target for which you're having problems a library
or an executable target?



Is this the same as it is used with the NMake Generator?

If so, please don't make this the default.  It makes it impossible to 
see what the link line is when make VERBOSE=1.


Or just have it turn on only when the line actually does exceed the limits.


--
Gonzalo Garramuño
[EMAIL PROTECTED]

AMD4400 - ASUS48N-E
GeForce7300GT
Xubuntu Gutsy
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Re: Parsing cmake command line parameters

2007-12-18 Thread Gonzalo Garramuño

Alexander Neundorf wrote:

Yes.
In KDE we have the macro MACRO_OPTIONAL_FIND_PACKAGE(), which adds an option
around the find_package() call:

http://websvn.kde.org/trunk/KDE/kdelibs/cmake/modules/MacroOptionalFindPackage.cmake?revision=520790view=markup

Beside that, it is really just a matter of syntax whether you do
--enable-build-this

or -DENABLE_BUILD_THIS=TRUE

No, it isn't *just* a matter of syntax (which is also horrible, btw).
It is also a matter of documentation. -DENABLE_BUILD_THIS is documented
nowhere. configure --enable-build-this is documented if you run it
without any flag.

But... what if we have this extreme case?

IF(${CMAKE_BUILD_TYPE} STREQUAL Debug)
add_command_line_parameter(whatever)
ENDIF()

So? You don't get the option if you don't run a debug build. As simple
as that. A better syntax for add_option would be:

add_option( NAME TYPE HELP [OPTS] )

with OPTS being:
CONFIGURATION Debug
REQUIRED someotheroption

That avoids the need for if-thens.

I have (currently) two ideas:
either a special file, e.g. CMakeCustomArgs.txt, which in some way sets up the
custom command line parameters.

Yuck!

Or have a cmake modules, which handles this stuff, and which also creates a
custom target help-args or something like that, which prints the available
args. This would not be available before cmake has successfully run.

Yuck! Why wouldn't it be available? Have you guys used premake at all?
The premake.lua is ALWAYS read. If no parameter is passed, there's a
dry run of the file, and help with options get spit.

It is gorgeous.
Sure, lua runs 10 times faster than the cmake language does, but that's
a different story.

--
Gonzalo Garramuño
[EMAIL PROTECTED]

AMD4400 - ASUS48N-E
GeForce7300GT
Xubuntu Gutsy
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] premake build system


Filipe Sousa wrote:

For those who love lua and want a build system there is premake
http://industriousone.com/premake

And I know that there is another build system that uses lua but I can't
find the link.



premake3/4 is tiny and its syntax is *really* nice.

What's similar to cmake:
- It creates Makefiles or IDE projects.

What's better than cmake (imho):
- Language syntax.
- You can easily add command-line flags like autotools.
- Install options match autotools.
- Tiny (only a couple of secs to compile it from source).
- Written in C (more easily ported than cmake).
- Makefiles generated are simple, readable and faster.
- C code is very readable and easy to follow.
- Uses relative paths.


What's worse:
- No dependency checking on .h files at all (yuck).
- Out-of-source builds is a property of the
  premake.lua script (yuck).
- Verbose builds is a feature of premake, not the Makefile,
  meaning you need to regenerate the makefile each time to
  get verbose output (yuck).
- No find_path or find_include
- No cross-platform modules for better support.
- Small language and compiler support.
- No coloring of builds.
- No testing framework.
- No packaging framework.
  (what they call dopackage is really doinstall)
- C code is a tad disorganized.
- No listing of make targets (no make help).


I really like it much better than the scons derivatives, but the lack of 
proper dependency checking is a killer.



--
Gonzalo Garramuño
[EMAIL PROTECTED]

AMD4400 - ASUS48N-E
GeForce7300GT
Xubuntu Gutsy
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] premake build system


Brandon Van Every wrote:

On Dec 17, 2007 5:46 AM, Gonzalo Garramuño [EMAIL PROTECTED] wrote:

premake3/4 is tiny and its syntax is *really* nice.


... Show me a tool that does something CMake

*can't* do, or does badly. ...

Well, in the quote that you did not keep, I posted that premake *is* a 
good example of a couple of things cmake cannot do (command-line flags 
and OO).  And syntax is certainly one of the things cmake does badly. 
Bad support (lack of, really) for relative paths is another weakness in 
cmake.


So premake is definitively a good example for what you want.

To be honest, if premake did dependencies right (or at least like waf 
does), I would certainly consider it as a valid alternative to cmake.


When Alex was asking about what for? in another thread, I think my 
quick eval of other systems proves to me your quest is not in vain.


I honestly don't think it will take 10 more years for a tool to match 
the benefits of cmake with a better syntax.  As I have said before, I 
think it is only 3 or so years away from happening.



--
Gonzalo Garramuño
[EMAIL PROTECTED]

AMD4400 - ASUS48N-E
GeForce7300GT
Xubuntu Gutsy
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Re: premake build system


Rodolfo Schulz de Lima wrote:
So, apart of forking, a build system that wants to be better than cmake 
should reimplement 90% of cmake's features, just to add those 10% missing?




Kind of.  Not really 90%, but more like 60-70%.  It would first have to:

* gotten dependencies correct (this is really hard).
* be fast in every aspect (hard without coding it in c/c++).
* be multi-platform.

Without those three, nothing else matters.  Once those are okay, you 
need to:


* support a couple of languages (say c++ and java).
* have an easy to extend (and well defined) framework.
  If, say, swig is not supported, but the framework is
  defined, someone else should be able to write a module for it.
* support a couple of common IDEs and compilers (mainly
  gcc and msvc).  Others will appear as need arises.
* have support to find files on disk (includes, libs, exes).
* have decent docs or at least a bunch of examples.
* be well supported with a mailing list
  (and not a dead one like jam).

Getting all that right is *HARD* and can easily be a full-time job.
Most of cmake competitors have not yet full-filled all of the above. 
Ergo, why cmake still rules.


Additional components like cpack or ctest are a plus, but they are not 
a major reason for sticking with cmake.


While a large amount of cmake's modules is nice when you start with it, 
it is not a deal breaker if the framework is good (and a good OO 
framework should be better than what cmake does with FIND_PACKAGE).


Things that would also earn tons of brownie points would be:
* smaller than cmake (both to compile and distribute).
* good for cross-compilation.



--
Gonzalo Garramuño
[EMAIL PROTECTED]

AMD4400 - ASUS48N-E
GeForce7300GT
Xubuntu Gutsy
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Re: premake build system


Bill Hoffman wrote:

Gonzalo Garramuño wrote:


* good for cross-compilation.

CVS CMake (and the coming 2.6 CMake) have extensive support for cross 
compilation.


http://www.cmake.org/Wiki/CMake_Cross_Compiling



I'm still having a lot of problems with it.  Even cross-compiling on a 
64-bit machine for 32-bit builds is, afaik, not really possible without 
major hacking of Platform/UnixPaths.



--
Gonzalo Garramuño
[EMAIL PROTECTED]

AMD4400 - ASUS48N-E
GeForce7300GT
Xubuntu Gutsy
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Re: premake build system


Bill Hoffman wrote:
It is harder than you think, but maybe you are right. If you look at 
Ohloh:  http://www.ohloh.net/projects/3238?p=CMake


It shows CMake as a 51 person year project at a cost of 2.7 million. 
That may not actually be far from the mark...




Well, following the same standard, imagine if you were using a common 
language like Ruby which is 125 person year project at a cost of 6 million.


You'd have had 4 million to spare and 50+ additional year/developers to 
begin with even before you wrote your first cmake line!




--
Gonzalo Garramuño
[EMAIL PROTECTED]

AMD4400 - ASUS48N-E
GeForce7300GT
Xubuntu Gutsy
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [Spam] Re: [CMake] Re: premake build system


Alexander Neundorf wrote:

On Monday 17 December 2007, Gonzalo Garramuño wrote:

Bill Hoffman wrote:

Gonzalo Garramuño wrote:

* good for cross-compilation.

CVS CMake (and the coming 2.6 CMake) have extensive support for cross
compilation.

http://www.cmake.org/Wiki/CMake_Cross_Compiling

I'm still having a lot of problems with it.  Even cross-compiling on a
64-bit machine for 32-bit builds is, afaik, not really possible without
major hacking of Platform/UnixPaths.


Ok, what are you doing exactly, what are the problems ?




First, trying simple 32-bit compiles on a 64-bit machine (Ubuntu OS).

For 32-bit compiles on a 64-bit machine, the problem is that UnixPaths 
does not change the location where it searches for files.


First, CMAKE_SYSTEM_LIBRARY_PATH is set incorrectly to always search 
lib/ paths instead of lib32/ or lib64/ paths.  This will create warnings 
for the most part as the linker is usually smart.  However, if a library 
is not present on 32-bits, the 64-bits file will get picked up and the 
problem will only appear show up when linking, not during configuration.


CMAKE_SYSTEM_PROGRAM_PATH also suffers from a similar issue.  This is an 
issue with modules that use pkgconfig, for example or that set settings 
from finding executables like ruby.  It isn't entirely clear to me if 
there is a standard location for 32-bit bin files (not libs) in Linux, thou.


CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES is also wrong, adding both 64 
and 32 bits paths.


Afaik, there's no variable indicating whether to compile for 32bits or 
not.  And cmake does not check for the -m32 flag at all.


I have my own UnixPaths and modules to work around most of the above, 
but it would be good to have this working out of the box.


Recent versions of cmake seem to have also added this:

# Enable use of lib64 search path variants by default.
SET_PROPERTIES(GLOBAL PROPERTIES FIND_LIBRARY_USE_LIB64_PATHS TRUE)

which seems highly undesirable or a so far undocumented feature.


---
For cross-compiling, I was trying to do some compiles from my Unix box 
to windows using a unix-mingw32 to windows toolchain.  I was utterly 
unsuccessful.  I just kept fixing one error only to find another one.  I 
had followed the cmake wiki for cross-compiling, but there were still 
many issues with paths in modules and the like.  If you want to walk me 
thru it, I'll start a new thread with the errors I find as I go thru it 
again.  Mind you, the stuff I want to compile has many dependencies, so 
it is a hard thing to do.



--
Gonzalo Garramuño
[EMAIL PROTECTED]

AMD4400 - ASUS48N-E
GeForce7300GT
Xubuntu Gutsy
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [Spam] Re: [CMake] Re: premake build system


David C Thompson wrote:

Gonzalo Garramuño wrote:

Alexander Neundorf wrote:

On Monday 17 December 2007, Gonzalo Garramuño wrote:

Bill Hoffman wrote:

Gonzalo Garramuño wrote:

* good for cross-compilation.

CVS CMake (and the coming 2.6 CMake) have extensive support for cross
compilation.

http://www.cmake.org/Wiki/CMake_Cross_Compiling

I'm still having a lot of problems with it.  Even cross-compiling on a
64-bit machine for 32-bit builds is, afaik, not really possible without
major hacking of Platform/UnixPaths.

Ok, what are you doing exactly, what are the problems ?

First, trying simple 32-bit compiles on a 64-bit machine (Ubuntu OS).

For 32-bit compiles on a 64-bit machine, the problem is that UnixPaths 
does not change the location where it searches for files.


Are you using setarch i386 cmake ? That should help by forcing uname
to advertise the architecture as 32-bit.



No, I'm not.  But using it does not seem to improve things that much. 
Still lots of paths get picked up wrong due to bad UnixPaths.cmake.


In my case, X11 and GL get picked from the 64-bit paths instead of 
32-bits (and yes, I have 32-bits versions in /usr/lib32).


For example:

-- Found X11: /usr/lib64/libX11.so---
It is impossible to order the linker search path in such a way that 
libraries specified as full paths will be picked by the linker.

Directories and libraries involved are:
Directory: /usr/lib32 contains:
Library: /usr/lib64/libGL.so
Library: /usr/lib64/libGLU.so

Directory: /usr/lib64 contains:
Library: /usr/lib32/libz.so
Library: /usr/local/lib32/libHalf.a
Library: /usr/local/lib32/libIex.a
Library: /usr/local/lib32/libIlmImf.a
Library: /usr/local/lib32/libImath.a


--
Gonzalo Garramuño
[EMAIL PROTECTED]

AMD4400 - ASUS48N-E
GeForce7300GT
Xubuntu Gutsy
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Re: premake build system


Alexander Neundorf wrote:

I have my own UnixPaths and modules to work around most of the above,


Can you please post it ?



Sure.  It is really two pieces.  FindBuildDir.cmake which is called 
first and Platforms/UnixPaths.cmake.


FindBuildDir does the hard check of setting up a couple of variables. 
It sets CMAKE_NATIVE_ARCH to 32 or 64.


And sets the OS_32_BITS and OS_64_BITS variables to represent whether 
the machine can compile for that.


User calls (optionally) cmake with -DCMAKE_BUILD_ARCH=32 to build in 32 
bits.


Currently, I only have it working for Linux (tested) and Sun (not 
tested).  Windows and OSX are todo, as I don't have access to 64-bit 
versions of them.



UnixPaths.cmake is then set to search for 
/usr/local/lib${CMAKE_BUILD_ARCH} before it searches for any 
/usr/local/lib and other.


This is still kind of screwy now because try-compile will call 
UnixPaths.cmake without calling my FindBuildDir, which is a bug in how 
cmake deals with variables.



--
Gonzalo Garramuño
[EMAIL PROTECTED]

AMD4400 - ASUS48N-E
GeForce7300GT
Xubuntu Gutsy
#-*-cmake-*-
#
# This simple CMake extension makes sure that builds get
# created inside a BUILD/os-osversion-arch directory
# and that executables, obj files and lib files get placed
# correctly in subdirectories.
#
#
# Macro to check architecture
#
MACRO( CHECK_ARCHITECTURE )


  IF( NOT CMAKE_BUILD_ARCH )
SET( CMAKE_BUILD_ARCH $ENV{CMAKE_BUILD_ARCH} )
IF( NOT CMAKE_BUILD_ARCH )
  SET( CMAKE_BUILD_ARCH Native )
ENDIF( NOT CMAKE_BUILD_ARCH )
  ENDIF( NOT CMAKE_BUILD_ARCH )

  IF( NOT CMAKE_BUILD_ARCH MATCHES ^(Native|64|32)$ )
MESSAGE( FATAL_ERROR 
  CMAKE_BUILD_ARCH set but invalid.  
  Only Native, 64 and 32 are valid settings )
  ENDIF( NOT CMAKE_BUILD_ARCH MATCHES ^(Native|64|32)$ )

  #
  # Set Native architecture based on void* size
  #
  INCLUDE(CheckTypeSize)
  CHECK_TYPE_SIZE(void*  SIZEOF_VOID_PTR)

  IF( ${SIZEOF_VOID_PTR} MATCHES ^8$ )
SET( OS_32_BITS 0 )
SET( OS_64_BITS 1 )
SET( CMAKE_NATIVE_ARCH 64 )
  ELSE( ${SIZEOF_VOID_PTR} MATCHES ^8$ )
SET( OS_32_BITS 1 )
SET( OS_64_BITS 0 )
SET( CMAKE_NATIVE_ARCH 32 )
  ENDIF( ${SIZEOF_VOID_PTR} MATCHES ^8$ )

  MESSAGE( FATAL_ERROR void size: ${SIZEOF_VOID_PTR} )

  IF( UNIX )
EXECUTE_PROCESS( 
  COMMAND uname -a
  OUTPUT_VARIABLE OS_ARCH 
  )

#
# For Linux
#
IF( OS_ARCH MATCHES .*Linux.* )
  IF( OS_ARCH MATCHES .*x86_64.* )
SET( OS_32_BITS 1 )
  ELSEIF( OS_ARCH MATCHES .*ia64.* )
SET( OS_32_BITS 0 )
  ELSEIF( OS_ARCH MATCHES .*i686.* )
SET( OS_32_BITS 1 )
  ENDIF( OS_ARCH MATCHES .*x86_64.* )
ENDIF( OS_ARCH MATCHES .*Linux.* )

#
# For SUN
#
IF( OS_ARCH MATCHES .*SunOS.* )
  EXECUTE_PROCESS( 
COMMAND isainfo -v
OUTPUT_VARIABLE SUNOS_ARCH 
)

  IF ( SUNOS_ARCH MATCHES .*64-bit.* )
SET( OS_32_BITS 1 )
  ENDIF(  SUNOS_ARCH MATCHES .*64-bit.* )

ENDIF( OS_ARCH MATCHES .*SunOS.* )

IF( APPLE )
  #
  # @todo: add Apple 64-bit OS detection here
  #
ENDIF( APPLE )

  ELSE( UNIX )

#
# @todo: add windows 64-bit OS detection here
#

  ENDIF( UNIX )


  IF ( CMAKE_BUILD_ARCH STREQUAL Native )
SET( CMAKE_BUILD_ARCH ${CMAKE_NATIVE_ARCH} )
  ENDIF( CMAKE_BUILD_ARCH STREQUAL Native )

  IF( CMAKE_BUILD_ARCH EQUAL 32 )

IF( NOT OS_32_BITS )
  MESSAGE( FATAL_ERROR 
Sorry, but this platform cannot compile 32-bit applications )
ENDIF( NOT OS_32_BITS )

IF( NOT CMAKE_NATIVE_ARCH EQUAL 32 )

  IF( WIN32 )
  ELSE( WIN32 )

IF( CMAKE_COMPILER_IS_GNUCXX )
  ADD_DEFINITIONS( -m32 )
  SET( LINK_FLAGS -m32 ${LINK_FLAGS} )
ELSE( CMAKE_COMPILER_IS_GNUCXX )

  #
  # @todo: add 32-bit compile flags for non-GNU compilers here
  #
  
ENDIF( CMAKE_COMPILER_IS_GNUCXX )
  ENDIF( WIN32 )

ENDIF( NOT CMAKE_NATIVE_ARCH EQUAL 32 )

  ENDIF( CMAKE_BUILD_ARCH EQUAL 32 )

ENDMACRO( CHECK_ARCHITECTURE )


CHECK_ARCHITECTURE()

#
# Store build type
#
IF(NOT CMAKE_BUILD_TYPE)
  SET(CMAKE_BUILD_TYPE Release CACHE STRING
  Choose the type of build, options are: None Debug Release RelWithDebInfo 
MinSizeRel.
  FORCE)
ENDIF(NOT CMAKE_BUILD_TYPE)

IF( CMAKE_BUILD_TYPE STREQUAL Debug )
  ADD_DEFINITIONS( -DDEBUG )
ENDIF( CMAKE_BUILD_TYPE STREQUAL Debug )

IF( NOT CMAKE_SYSTEM )
  MESSAGE( FATAL_ERROR CMAKE_SYSTEM was not set )
ENDIF( NOT CMAKE_SYSTEM )

#
# @bug in cmake2.5 in windows (workaround)
#
IF( NOT CMAKE_SYSTEM_VERSION )
  SET( CMAKE_SYSTEM_VERSION 5.1 )
  SET( CMAKE_SYSTEM ${CMAKE_SYSTEM}-${CMAKE_SYSTEM_VERSION} )
ENDIF( NOT CMAKE_SYSTEM_VERSION )


IF( NOT CMAKE_BUILD_TYPE )
  MESSAGE( FATAL_ERROR CMAKE_BUILD_TYPE was not set )
ENDIF( NOT CMAKE_BUILD_TYPE )

IF( NOT CMAKE_BUILD_ARCH )
  MESSAGE( FATAL_ERROR CMAKE_BUILD_ARCH was not set )
ENDIF( NOT CMAKE_BUILD_ARCH )


SET( BUILD_DIR

Re: [CMake] Waf build tool

2007-12-16 Thread Gonzalo Garramuño


Brandon Van Every wrote:

On Dec 15, 2007 1:55 PM, Brandon Van Every [EMAIL PROTECTED] wrote:

I've subscribed to the SCons mailing list.  The SCons community has
people who got fed up with it and started their own RD.  It seems
that the SCons Python 1.5 limitation is a serious one, as developers
generally only know Python = 2.2.  Waf is the offering of a fellow
who clearly thinks OO is important in a build system for some reason.
http://code.google.com/p/waf/



A quick eval of waf

* Its dependency checker is broken.
  /usr/include is not checked for speed.
* Swig support is broken.
* no real multi platform support, it is all do it yourself.
* out-of-source builds is kind of broken.
* proper out-of-source builds needs the wscript to be set up
  with variants (good idea, but badly done).
* build dir creates stubs for all subdirectories, not only
  those in build (yuck).
* no listing of tasks (yuck).
* you are always forced to write a configure function (yuck).
* WAY too verbose (yuck).
* badly documented.

In summary, thanks.  But, no thanks.  With all those problems I did not 
even bother checking the speed.





--
Gonzalo Garramuño
[EMAIL PROTECTED]

AMD4400 - ASUS48N-E
GeForce7300GT
Xubuntu Gutsy
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Waf build tool

2007-12-16 Thread Gonzalo Garramuño


Alexander Neundorf wrote:


What's the purpose ?
CMake is kind-of going OO.



Meaning *what*, exactly?


Do you mean that
a) say FILE( READ ... )
will change to:
   File.read()  or x.read() where x is a file object?

   and LIST( APPEND ... )
   will be just a.append(x) or a += x

b) you'll be able to do:

class A
   attr_accessor :x
   def f( x )
  @x = x + 5
   end
end

class B  A
   def t(); end
end

a = A.new
a.x
a.f
a.x = 5

b = B.new
b.x
b.f
b.t

c) you'll have 'virtual' macros?
class A
   def f( x ); end
end

class B  A
   def f( x )
super
   end
end

a = A.new
b = B.new
b.f(1) # calls B::f, which in turn can call A::f, too.
a.f(1) # calls A::f

d) ...other...

I consider a) to c) the cornerstone of OO.  b and c cannot be done in 
cmake.  a) can (only partially) be done and with an uglier syntax.



--
Gonzalo Garramuño
[EMAIL PROTECTED]

AMD4400 - ASUS48N-E
GeForce7300GT
Xubuntu Gutsy
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Including of Platform/UnixPaths.cmake now broken

2007-12-10 Thread Gonzalo Garramuño



This used to work properly, but it has now changed behavior and is now 
borken.


Using CVS version, somewhat latest one.
cmake version 2.5-20071026

I have:

SET( CMAKE_MODULE_PATH  ${CMAKE_CURRENT_SOURCE_DIR}/modules )

to change cmake's search path behavior.

Inside my local modules dir, I have Platform/UnixPaths.cmake, to fix 
cmake's searching of 32-bit stuff on a 64-bit machine when -m32 is used.


I use my own variable -DCMAKE_BUILD_ARCH=32 to determine whether I am 
compiling 32-bits on a 64-bits machine.


The problem is that cmake now goes to check compiler and it runs 
Platform/UnixPaths.cmake without passing any of my variables to it (ie. 
CMAKE_BUILD_ARCH=).


Then, after it calls the compiler check, it seems it caches the 
CMAKE_SYSTEM_PATH and does not call Platform/UnixPaths anymore during 
the running of my CMakeLists.txt file.


Other local modules do get picked correctly with my variables set, so 
CMAKE_MODULE_PATH works ok, but not for Platform/UnixPaths.cmake.


This results in CMAKE_SYSTEM_PATH being set wrong (and thus, my compile 
not to work).


Previous versions would invoke UnixPaths.cmake multiple times, so even 
though the compiler check would call it wrongly without any variable 
set, during the course of my actual run of the CMakeLists.txt file, it 
would get called again but with my vars set, which allowed me to set the 
path correctly.


I'm either looking for:
	a) A correct UnixPaths.cmake module that handles 32-bits libs properly 
(the current one in CVS does not).


or

b) A fix to this broken behavior.



--
Gonzalo Garramuño
[EMAIL PROTECTED]

AMD4400 - ASUS48N-E
GeForce7300GT
Xubuntu Gutsy
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] cmake, lex yacc

2007-12-06 Thread Gonzalo Garramuño


Timur Ivanov wrote:

Hello!

Sorry if it was discussed already but I can't find anything really
useful for me.

In current project I use lex  yacc and Makefile rules looks like:



cmake currently does not ship with bison and flex modules, 
unfortunately.  Here's a couple of mine.


--- FindFlex.cmake
# - Try to find Flex
# Once done this will define
#
#  FLEX_FOUND - system has Flex
#  FLEX_EXECUTABLE - path of the flex executable
#  FLEX_VERSION - the version string, like 2.5.31
#


FIND_PROGRAM(FLEX_EXECUTABLE NAMES flex flex.exe )

IF(FLEX_EXECUTABLE)
SET(FLEX_FOUND TRUE)

EXECUTE_PROCESS(COMMAND ${FLEX_EXECUTABLE} --version
OUTPUT_VARIABLE _FLEX_VERSION
)
string (REGEX MATCH [0-9]+\\.[0-9]+\\.[0-9]+ FLEX_VERSION 
${_FLEX_VERSION})

ENDIF(FLEX_EXECUTABLE)

IF(FLEX_FOUND)
  IF(NOT Flex_FIND_QUIETLY)
MESSAGE(STATUS Found Flex: ${FLEX_EXECUTABLE})
  ENDIF(NOT Flex_FIND_QUIETLY)
ELSE(FLEX_FOUND)
  IF(Flex_FIND_REQUIRED)
MESSAGE(FATAL_ERROR Could not find Flex)
  ENDIF(Flex_FIND_REQUIRED)
ENDIF(FLEX_FOUND)
---

 FindBison.cmake
# - Try to find Bison
# Once done this will define
#
#  BISON_FOUND - system has Bison
#  BISON_EXECUTABLE - path of the bison executable
#  BISON_VERSION - the version string, like 2.5.31
#

FIND_PROGRAM(BISON_EXECUTABLE NAMES bison bison.exe )

IF(BISON_EXECUTABLE)
SET(BISON_FOUND TRUE)

EXECUTE_PROCESS(COMMAND ${BISON_EXECUTABLE} --version
OUTPUT_VARIABLE _BISON_VERSION
)
string (REGEX MATCH [0-9]+\\.[0-9]+\\.[0-9]+ BISON_VERSION 
${_BISON_VERSION})

ENDIF(BISON_EXECUTABLE)

IF(BISON_FOUND)
  IF(NOT Bison_FIND_QUIETLY)
MESSAGE(STATUS Found Bison: ${BISON_EXECUTABLE})
  ENDIF(NOT Bison_FIND_QUIETLY)
ELSE(BISON_FOUND)
  IF(Bison_FIND_REQUIRED)
MESSAGE(FATAL_ERROR Could not find Bison)
  ENDIF(Bison_FIND_REQUIRED)
ENDIF(BISON_FOUND)
--

--- Sample usage


FIND_PACKAGE( Flex  REQUIRED)
FIND_PACKAGE( Bison REQUIRED)

#
# Create custom command for flex/lex (note the outputs)
#
ADD_CUSTOM_COMMAND(
   SOURCE ${CMAKE_CURRENT_SOURCE_DIR}/grammar.lex
   COMMAND ${FLEX_EXECUTABLE}
   ARGS -o${CMAKE_CURRENT_BINARY_DIR}/lex.yy.c
-Pmrl_yy -8 -CFe ${CMAKE_CURRENT_SOURCE_DIR}/grammar.lex
   TARGET miparser
   OUTPUTS ${CMAKE_CURRENT_BINARY_DIR}/lex.yy.c
   )

#
# Create custom commands for bison/yacc (note the DEPENDS)
#
ADD_CUSTOM_COMMAND(
  SOURCE ${CMAKE_CURRENT_SOURCE_DIR}/grammar.y
  COMMAND ${BISON_EXECUTABLE}
  ARGS -l -pmrl_yy  -o${CMAKE_CURRENT_BINARY_DIR}/grammar.tab.cpp
 ${CMAKE_CURRENT_SOURCE_DIR}/grammar.y
  TARGET miparser
  DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/lex.yy.c
  OUTPUTS ${CMAKE_CURRENT_BINARY_DIR}/grammar.tab.cpp
)



--
Gonzalo Garramuño
[EMAIL PROTECTED]

AMD4400 - ASUS48N-E
GeForce7300GT
Xubuntu Gutsy
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] cmake, lex yacc

2007-12-06 Thread Gonzalo Garramuño


Gonzalo Garramuño wrote:

Timur Ivanov wrote:

Hello!

Sorry if it was discussed already but I can't find anything really
useful for me.

In current project I use lex  yacc and Makefile rules looks like:



cmake currently does not ship with bison and flex modules, 
unfortunately.  Here's a couple of mine.




Silly me replying to a year old thread...  apologies to all.


--
Gonzalo Garramuño
[EMAIL PROTECTED]

AMD4400 - ASUS48N-E
GeForce7300GT
Xubuntu Gutsy
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Changing compiler at runtime

2007-11-24 Thread Gonzalo Garramuño



Recently, Josef Karthauser was requesting the ability to change the 
compiler at runtime.


I am now more or less seconding that request or asking for workarounds.

The situation:
	I have a complex project built for windows that has several plug-ins 
that, for each version of the project, needs to be compiled with a 
particular compiler version to keep binary compatibility.  Thus, my v3.0 
needs to be built against vc6, my v4.0 against vc7.1, my v5.0 against 
vc8, etc.
	I am automating the build process for each build as an out of source 
build, but I also need to automate the changing of the compiler.




--
Gonzalo Garramuño
[EMAIL PROTECTED]

AMD4400 - ASUS48N-E
GeForce7300GT
Xubuntu Gutsy
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] $ENV{HOSTNAME}

2007-11-21 Thread Gonzalo Garramuño


Salvatore Iovene wrote:


A bug? Thanks.



Nope.

$ echo $HOSTNAME
aura1

$ sh -c echo \$HOSTNAME

$ bash -c echo \$HOSTNAME
aura1

Basically, HOSTNAME is a variable that is set by some shells like bash 
only, but cmake for speed and consistency runs commands using the most 
basic unix shell (ie. sh), which does not set that variable by default.


--
Gonzalo Garramuño
[EMAIL PROTECTED]

AMD4400 - ASUS48N-E
GeForce7300GT
Kubuntu Edgy
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Default search paths for FIND_PATH

2007-11-19 Thread Gonzalo Garramuño


Stephen Collyer wrote:

Alexander Neundorf wrote:


The defaults are set in Modules/Platform/UnixPath.cmake and WindowsPaths.cmake


Thanks for that. There's one thing I don't understand: in
UnixPath.cmake, the search paths are set to a set of hard-coded
absolute paths, as I would expect. However, in WindowsPaths.cmake,
the search paths are set to the value of $ENV{ProgramFiles} which
I assume is the value of that environment variable. 



Blame windows localization for that.

%ProgramFiles% is a windows built-in environment variable.  Its value 
varies depending on your Windows native language and version, but I 
believe it is set in the Configuration-System-Advance 
Options-Environment Variables (System/All users section).  The value is 
set upon installation of windows.


In English, it is usually C:\Program Files.  In Spanish, it may be 
C:\Archivos de Programa.  Etc.


It is often a problematic variable for build systems (and installers) 
due to the built-in space(s) in its path, albeit cmake should be able to 
work around that issue.



--
Gonzalo Garramuño
[EMAIL PROTECTED]

AMD4400 - ASUS48N-E
GeForce7300GT
Kubuntu Edgy
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] No FileIsSymlink(...) for Win32?

2007-11-14 Thread Gonzalo Garramuño


Miguel A. Figueroa-Villanueva wrote:


Isn't there a way to detect the shortcut in win32 and not create the
directory if it exists? Something equivalent to:



The short answer is that no.  Shortcuts are basically a property of the 
Windows GUI environment, not of the file system.  As such, all 
command-line tools in windows don't respect them.  cmake, being a 
command-line tool, should behave like other command-line tools.


A Windows shortcut is a really a text file with a .lnk extension.  As 
such, it is different from an actual directory with the same name.


Shortcuts are not really symbolic links at all.  Windows to this day 
does not have symbolic links as Unix does, so it would be incorrect to 
use any of those functions to work with shortcuts.


You may, however, want to request a function to parse shortcuts, albeit 
you can probably write it in .cmake yourself (as it a .lnk file is just 
a text file).


--
Gonzalo Garramuño
[EMAIL PROTECTED]

AMD4400 - ASUS48N-E
GeForce7300GT
Kubuntu Edgy
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] No FileIsSymlink(...) for Win32?

2007-11-14 Thread Gonzalo Garramuño


Pau Garcia i Quiles wrote:
Windows 2000 Server, XP and 2003 Server, at least, include a linkd.exe 
utility which creates actual symlinks. It only works on NTFS 
filesystems, AFAIK, but it works well. Active Directory relies uses 
linkd'd directories in several places (for instance, SYSVOL and 
SYSVOL/domain).


Nope.  Contrary to Microsoft propaganda, those are not symbolic links 
but junction points.  Junction points offer a kind of limited symbolic 
link but only on directories.  Files are treated as hard-links.  And 
neither one can be relative or cross volumes.  They also suffer from 
problems with cycles.  And, as you say, only under a certain file 
system.  The windows api also does not expose these properly on a 
network either (unlike Samba), so OSes that are not those versions 
cannot access them.


Windows Vista includes the first real attempt to add symlinks, but they 
are still broken (and dramatically inferior) in comparison to Unix. 
Similar limitations: a max of 31 in a directory, relative symlinks 
cannot cross volumes, you manually need to distinguish between files and 
directories when creating or deleting them, they don't show up to other 
machines on the network that are not vista, etc.


So, in summary, no.  I stand by my statement.  No Microsoft OS to this 
day supports symbolic links.


--
Gonzalo Garramuño
[EMAIL PROTECTED]

AMD4400 - ASUS48N-E
GeForce7300GT
Kubuntu Edgy
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] INSTALL TARGETS modifies files on some platforms.

2007-11-12 Thread Gonzalo Garramuño


Magnus Sirwiö wrote:

Hi,

I have notices strange behavior when using the INSTALL rule with the 
TARGETS signature as shown below:




It is normal behavior.  install strips and relinks your executables 
before install.  This removes useless data like debugging symbols, 
making your executables smaller.


--
Gonzalo Garramuño
[EMAIL PROTECTED]

AMD4400 - ASUS48N-E
GeForce7300GT
Kubuntu Edgy
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] gettext support and qtlinguist

2007-11-12 Thread Gonzalo Garramuño


Leopold Palomo-Avellaneda wrote:

Hi,

someone knows if there's some module to support the gettext functions and pot 
generation?


cmake2.5 (SVN) has a FindGettext.cmake.  You can use the module with 
2.4.7, too.



--
Gonzalo Garramuño
[EMAIL PROTECTED]

AMD4400 - ASUS48N-E
GeForce7300GT
Kubuntu Edgy
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] gettext support and qtlinguist

2007-11-12 Thread Gonzalo Garramuño


Leopold Palomo-Avellaneda wrote:



cmake2.5 cvs, not svn, no?



Yes, right.


and dou you know if someone is using it? an example?



I've used it.  It is pretty much self explanatory if you read the file.

FIND_PACKAGE( Gettext )
GETTEXT_CREATE_TRANSLATIONS ( potFile [ALL] pofile1 ... pofileN )


--
Gonzalo Garramuño
[EMAIL PROTECTED]

AMD4400 - ASUS48N-E
GeForce7300GT
Kubuntu Edgy
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] improve the CMake language?

2007-11-08 Thread Gonzalo Garramuño


Brandon Van Every wrote:


1) licenses that are unfriendly to unfettered commercial development,
often don't get accepted by commercial developers.  


Not really.

cmake is a stand-alone utility.  With any of the scripting language 
licenses, you can still ship cmake with your own, say, proprietary 
non-open source IDE.


For a utility like cmake that has very little use outside development, 
licensing is not going to be the main issue in making it more or less 
popular.  The main reason will be how good it is (or isn't).


If cmake was a popular C library on the other hand... the type of OSI 
licensing would indeed matter *much* more.




2) I don't personally make a habit of investing in software that
encumbers me.  MIT / BSD / zlib-libpng licenses allow me...


Right... I'll let it slide that your main platform of development is 
Windows.



And I agree with Juan, Lua sounds more
compelling than Ruby.


Brandon, my understanding is that you don't know neither ruby nor lua.
Before you make that kind of statement, you actually might want to spend 
some time actually using both languages first.




3) Your license choices are fine for your own use, but you'd need to
talk to Kitware about what they actually want.



Now, that could be a fair point.  If I was interested in having Kitware 
distribute cmake with ruby.  Which albeit I like the idea, I don't think 
I pushed for it.
As I said, I'm more interested in having a cmake have a language API or 
swig wrappings.  That way, I don't really have to make a commitment to a 
scripting language that can fall out of flavor later on.
I'd also rather offer people several options and let the best language 
arise naturally from that choice.  SWIG allows you to do that with the 
least pain, even if the project is under heavy development like cmake.


Also, you guys are just thinking of embedding the language into cmake. 
I think it is much easier (and less of a license trouble) to do the 
opposite.  Make cmake a *library* to the scripting languages.  That is 
(for ruby):


require 'cmake'
include CMake

generator = 'Unix Makefiles'
cxx_flags = -W 3
sources   = %w( hello.cpp )

add_executable( :hello, :sources = sources )
run



Sure.  That's from your POV.  For me, a language without good and easy
OO is a no-no as experience tells me it will sooner or later run into
scalability and maintainability issues.  That makes TCL and Lua to me
only minimally better than cmake's language in the long run.


What's the biggest build system you've yet written? 


Biggest, a custom one for a now defunct company.
Better one?  Industrial Light and Magic's.  Albeit I did not build it 
myself.  I was more or less consultant and beta tester for it.
cmake's source code in terms of .cmake files is already at the tipping 
point of begging for OO.


 The main ./configure

Err... by your own standard, you can't use that.  That is GPL only.

 It's not an exotic OO exercise;
that would be a waste of time.  


If you think OO is a waste of time and not a way to reduce your 400Mb of 
source code into probably 70Mb or less and enforcing consistency and 
readability, well...




Well that doesn't sound like the dumbest technical trick I've heard.
Could it help with parallel builds?



Nope.  Parallel builds in cmake are handled by your make program, not 
cmake.



--
Gonzalo Garramuño
[EMAIL PROTECTED]

AMD4400 - ASUS48N-E
GeForce7300GT
Kubuntu Edgy
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] improve the CMake language?

2007-11-07 Thread Gonzalo Garramuño


Juan Sanchez wrote:

I was reading exactly the link you sent, and the same one you accused
Brandon of not reading.  If there were supplemental materials, you
should have sent them.  I am not a lawyer.



To Juan:
Yes.  The best place for any license question about source code is, as 
usual, the source code.  In ruby's case, its source code is in SVN at:


  svn co http://svn.ruby-lang.org/repos/ruby/trunk  ruby1.9

That's where you will find LEGAL which has probably the most up to date 
status of each file not entirely written by the ruby team.


If you need further clarification about a source file, you should ask 
probably in the ruby-core's mailing list.


Also, this is only about the (most popular and currently faster) C Ruby 
we are talking about.  There's several other ruby interpreters which are 
under other licenses.


To Brandon:  Sorry, yes, that was a mistype. I really meant Ruby is dual 
licensed as GPL and its own license.


Anyway... why are you guys so concerned about cmake's license?  To me, 
as long as the code is open source and forkable, that's all I care for 
cmake.  I'm not planning to make money selling a fork of cmake, borrow 
its source code, use cmake as a library nor embed it into another 
program, which are the reasons I might prefer a BSD/MIT license.




To be honest, the only compelling languages I've seen so far in this
discussion is lua and tcl.  This is because they are small and appear to
be ideal for embedding.



Sure.  That's from your POV.  For me, a language without good and easy 
OO is a no-no as experience tells me it will sooner or later run into 
scalability and maintainability issues.  That makes TCL and Lua to me 
only minimally better than cmake's language in the long run.


For me, I would accept either Python or Ruby as a better alternative, 
even if they are not as small.


TCL and Lua are only better for embedding if you were to need cmake to 
be multithreaded or if cmake would need to initialize a clean 
interpreter without quitting (two things, afaik, not needed or currently 
used in cmake).
Otherwise, there's not much difference with embedding Ruby, Python, etc. 
  Perl is the only language I would say that has a very difficult API 
for embedding.




Not that speed is super important, but I know of at least one hosting
provider making exceptions for ruby scripts, because they just take way
too long to run.


That's pretty funny.  Ruby (1.8) scripts run about the same speed as TCL 
(ie. neither one is known to be a speed daemon).  Ruby1.9 (to become the 
official ruby in 2008) runs at about the speed of Python (ie. much 
better than TCL).
Lua is certainly a faster language in terms of VM and numeric 
computations.  But for io, string, regex, etc. you are not likely to see 
a big difference.


The next link is *very* un-scientific and I don't endorse it.  But it is 
still an okay website to at least give you a very rough idea of performance:


http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=alllang=yarvlang2=python



--
Gonzalo Garramuño
[EMAIL PROTECTED]

AMD4400 - ASUS48N-E
GeForce7300GT
Kubuntu Edgy
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] improve the CMake language?

2007-11-07 Thread Gonzalo Garramuño


Sanchez, Juan wrote:
This part of the license would concern me.  Are all files of interest, 
by other authors, guaranteed to be BSD friendly?





Again, read LEGAL.  You will then find that:

regex when used with Ruby it is Ruby licensed, based on Onigurama.
utils is BSD, credit going to Lucent Technologies.
gcis Public Domain (Boehmm), albeit now is so heavily modified 
there's no resemblance to it any longer (probably the docs need updating).

stis Public Domain.

Other files may use Perl's Artistic License.


--
Gonzalo Garramuño
[EMAIL PROTECTED]

AMD4400 - ASUS48N-E
GeForce7300GT
Kubuntu Edgy
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] improve the CMake language?

2007-11-05 Thread Gonzalo Garramuño


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

Re: [CMake] improve the CMake language?

2007-11-05 Thread Gonzalo Garramuño


Brandon Van Every wrote:


I didn't realize that Ruby is GPLed.  http://www.ruby-lang.org/en/LICENSE.txt
Oh well, so much for embedding Ruby!


It isn't.  Where did you get that idea from !?  Brandon, you have a 
tendency to email FUD that is amazing... even when you provide links to 
text that clearly states exactly the opposite of what you say.


Ruby is distributed under a dual LGPL / Ruby License.  The Ruby License 
is a MIT-like license.
Some portions of ruby are not under that license (as they were not 
written by the author), but are either BSD (meaning you need to give 
proper credit) or public domain.


For proper info, refer to LEGAL in the ruby distribution.


--
Gonzalo Garramuño
[EMAIL PROTECTED]

AMD4400 - ASUS48N-E
GeForce7300GT
Kubuntu Edgy
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] improve the CMake language?

2007-11-02 Thread Gonzalo Garramuño

 oriented towards one 
or two platforms, so the need for a comprehensive multiplatform system 
like cmake is also probably overkill.



--
Gonzalo Garramuño
[EMAIL PROTECTED]

AMD4400 - ASUS48N-E
GeForce7300GT
Kubuntu Edgy

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Make clean - doesn't clean dependencies.

2007-11-01 Thread Gonzalo Garramuño


Josef Karthauser wrote:
It doesn’t appear that a ‘make clean’ in a subdirectory of the build 
tree cleans any of the dependencies.  Does anyone know of a way that it 
can be persuaded to?




make depend

For more info, cmake creates: make help

--
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] Re: [Swig-devel] Ruby test-suite

2007-10-26 Thread Gonzalo Garramuño


William S Fulton wrote:
Gonzalo, I've readying the release and have fixed a number of issues in 
the Ruby test-suite for Windows. There is a problem with std::set on 
Linux at the moment, I don't think I introduced it, but can't be sure as 
it is now late and I'm off to bed. I don't recall if Ruby was previously 
working on Linux. If you have a moment could you take a look? There are 
still a number of Windows problems if you have access to Windows, but 
I'll look at those tomorrow if not.


William


Yes, there's clearly some bad check-in somewhere along the way in the 
last 10 checkins.  Checkin 10039 seems to be one of the culprits.


It changed the iterators in set to const_iterators and there's no longer 
any non-const iterator there, which is probably a mistake.
Looking at my stl_set.h of latest gcc 4.1.2, most of the iterators are 
non-const.  Only some few functions return const_iterators.
I believe only the Key element in a set is to be defined const, not the 
iterators.


--
Gonzalo Garramuño
[EMAIL PROTECTED]

AMD4400 - ASUS48N-E
GeForce7300GT
Kubuntu Edgy
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Re: [Swig-devel] Ruby test-suite

2007-10-26 Thread Gonzalo Garramuño



apologize for the mail -- wrong mailing list.


--
Gonzalo Garramuño
[EMAIL PROTECTED]

AMD4400 - ASUS48N-E
GeForce7300GT
Kubuntu Edgy
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMakeSetup requires elevation on Vista

2007-10-25 Thread Gonzalo Garramuño


Brandon Van Every wrote:

On 10/23/07, Bill Hoffman [EMAIL PROTECTED] wrote:

The fix is in CVS CMake, but you have to build CMake with VS 8.  The
next release of CMake will have this fix in it.


Is VS8 a temporary or permanent requirement?  If permanent, are there
guards to keep people from building CMake with earlier versions of VS?
 I don't think we want a proliferation of Windows .exe's.



Don't do that.  People like myself are still compiling from source under 
VS7.1 and have no plans to upgrade to VS8.  Are you working for 
Microsoft these days, Brandon, that you want to force a U$1500 upgrade 
on people ? :)


I don't see anyone else other than www.cmake.org distributing cmake 
binaries, so there's not likely going to ever be a proliferation of 
windows .exe's.


--
Gonzalo Garramuño
[EMAIL PROTECTED]

AMD4400 - ASUS48N-E
GeForce7300GT
Kubuntu Edgy
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] MinGW broken on Vista

2007-10-25 Thread Gonzalo Garramuño


Brandon Van Every wrote:

If you try to run CMakeSetup with MinGW on Windows Vista, and you get
a screenful of errors including a line:



For vista you *probably* want a 64-bits mingw, not the 32-bits one.  Or 
a cross-compiler that runs on linux.  Google is your friend.



--
Gonzalo Garramuño
[EMAIL PROTECTED]

AMD4400 - ASUS48N-E
GeForce7300GT
Kubuntu Edgy
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake2.5 - wrong default install location for mingw

2007-10-23 Thread Gonzalo Garramuño

 cmake sanely, I honestly don't 
want to even try to maintain it.  I already support close to 10 open 
source projects and soon two closed source ones.  There's no way I could 
guarantee my modules work correctly with latest cmake.  Or debug those 
modules under MSYS, MSVC and MinGW (I'd have to choose one).
Yet one more example.  I am currently forking fltk2 (at least 
temporarily) with one of the goals to add cmake support, as properly 
keeping in sync VS files is, in my opinion, one thing that is slowing 
fltk2's development. 
Currently, it also builds using autotools under MSYS and as such it 
installs in /usr/local by default.  User's will expect that to keep 
working the same way.  Same thing will happen for any autotools project 
that works under msys that wants to move to cmake.  If each one of them 
needs to keep adding CMAKE_INSTALL_PREFIX and figuring out where msys is 
installed, there will be much less desire to move to cmake due to the 
headache and will likely soon lead to a mess of some CMakeLists.txt in 
each ported autotools project using some custom method to detect where 
msys is while others use another.   Nightmare.


Anyway, that's several examples why I would like cmake to follow 
msys/autotools policy under at least one generator.  The one called 
MSYS kind of seemed the more logical one.


P.S.  To be honest, I thought that just changing a default install 
locations was going to be a very simple request.  I cannot believe I've 
now spent 5 or 6 emails defending this position.


--
Gonzalo Garramuño
[EMAIL PROTECTED]

AMD4400 - ASUS48N-E
GeForce7300GT
Kubuntu Edgy

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake2.5 - wrong default install location for mingw

2007-10-21 Thread Gonzalo Garramuño


Bill Hoffman wrote:


Looks like a nice patch that you can put in your cmakelist files.  I 
still do not think it should go in CMake.  I don't think that things 
built by cmake that are native windows things belong in the /usr/local 
mount point of msys.   If you do, it is easy enough to change your 
project to install by default in anywhere you want.


Okay, I looked at the C++ code of MSYS generator.  And surprise, 
surprise.  It does EXACTLY what I said to do of searching the path (but 
looks for make.exe instead of sh.exe).  Also it uselessly (and somewhat 
potentially incorrectly) parses /etc/fstab to find where mingw's bin 
directory is (and does not cache any of the other paths, which could 
indeed potentially allow FIND_PATH() and others to work with mingw paths 
eventually).


The C++ code just forgets to set CMAKE_INSTALL_PREFIX to MSYS proper 
values.  I'll revert this .cmake patch and I'll give you a C++ patch of 
it instead, as the code is much cleaner that way.  And to be honest, I 
find the C++ code to be much more readable than the .cmake code (which 
is somewhat disturbing).


--
Gonzalo Garramuño
[EMAIL PROTECTED]

AMD4400 - ASUS48N-E
GeForce7300GT
Kubuntu Edgy

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake2.5 - wrong default install location for mingw

2007-10-20 Thread Gonzalo Garramuño


Bill Hoffman wrote:

 Not really true, cygwin has its own symlinks.  See here:
 http://www.cygwin.com/cygwin-ug-net/using.html

That's not a symlink.  That's a mount point.

And it does not effect anything I said.  Just try putting such a mount 
point on PATH (which is special).  It will get translated automatically 
whenever you call a DOS or windows app to an actual UNC or DOS path.



 Also see here:

 
http://www.mingw.org/MinGWiki/index.php/Shells%2C%20terminals%20and%20MSYS



Again, no contradiction to what I said.  cmake must run from one top 
shell or console, regardless of how many are nested.  That's the one you 
look as reference.
That's why I said looking at the envvar is a hack, while doing it with 
win32api is the proper way.



 So, even if you figured out what shell you were running from, you 
still could not write to /usr/local because that directory does not 
exist to a windows program.



No.  Did you read what I wrote?

Here's some code which may be easier.  I have MSYS and a standalone Ruby 
NOT compiled for msys.


$ cat /etc/fstab
c:/msys/1.0/mingw   /mingw
c:/ActiveState/perl /perl

$ echo $PATH
/usr/local/bin:/mingw/bin:/bin:/perl

# here i print path from ruby
$ /C/ruby/bin/ruby.exe -e puts ENV['PATH']
C:\msys\1.0\local\bin;c:\msys\1.0\mingw\bin;C:\msys\1.0\bin;c:\ActiveState\perl

# here I find sh.exe in path
$ /C/ruby/bin/ruby.exe -e puts ENV['PATH'].split(';').find {|dir| 
File.exists?( dir + '/sh.exe' ) }

C:\msys\1.0\bin

# here I get /usr/local
$ /C/ruby/bin/ruby.exe -e puts ENV['PATH'].split(';').find {|dir| 
File.exists?( dir + '/sh.exe' ) } + '../local'

C:\msys\1.0\bin\..\local

Explanation:

Find 'sh.exe' in $PATH.  PATH already has a DOS or UNC path from the 
MSYS/CYGWIN paths, regardless of how many mount points or 'symlinks' 
msys or cygwin uses.


From it, you have /usr/local by doing ../local ( or just .. if sh.exe 
happens to weirdly be in (ROOT)/local/bin which you can know from the 
word local in it).  Under any Unix (Linux) layer, sh.exe is not supposed 
to be installed ANYWHERE else and must exist in some form.


MSYS and CYGWIN *MUST* translate PATH to a windows equivalent or else 
child programs would not work correctly.  Other vars, like 
LD_LIBRARY_PATH don't get this special treatment.


--
Gonzalo Garramuño
[EMAIL PROTECTED]

AMD4400 - ASUS48N-E
GeForce7300GT
Kubuntu Edgy
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake2.5 - wrong default install location for mingw

2007-10-20 Thread Gonzalo Garramuño


Bill Hoffman wrote:


But hey CMake is open source, you can always add the code you want by 
yourself.


Here it is...  I put some questions in the comments as I'm not that 
familiar with the subtleties of some cmake's commands. 

You probably want to clean it up.  Took me too long to write (love cmake 
the make system and docs and platform and flexibility and support, but 
its language syntaxtoo much pain for my taste -- i never remember 
the commands).




As far as the other stuff...


 BTW both cygwin and msys have a ln to create symlinks:

Again, they are NOT symlinks.  In the same page you sent me it clearly 
specifies that those are not symlinks but get translated to mount points 
in /etc/fstab when they are dirs.  When they are files, you get a 
hardlink (and only if they are on NTFS!).  Not the same.  At least not 
at all to what the Unix world or Wikipedia calls symlinks.
Only with *Windows Vista* you can get actual symlinks in windows, but 
cygwin/mingw will likely not benefit from that anytime soon as they link 
against an old msvcrt for legal reasons.

Either way, this is offtopic and has *nothing* to do with what I asked.

 I am not going to add code into CMake that translates POSIX's paths 
into windows paths. 

You aren't and I did not ask for that.  You are always working with 
windows paths.   The conversion is handled by MSYS for you in the PATH 
variable AUTOMATICALLY.


 CMake would have to be a MSYS app to understand MSYS paths.

No.  But if you want to make FIND_PATH() and all the others also support 
MSYS mount points, be my guest.  That's not what I asked for, thou.


Or was all this just a trick to get me to become a cmake developer? :)

Anyway, if you want to go down that path of an MSYS cmake, rather than 
linking the cygwin/mingw library, have you considered just parsing 
/etc/fstab now that you know where it is as far as windows is 
concerned?  The big benefit of that is you maintain a single windows 
cmake that can generate all types of makefiles.


--
Gonzalo Garramuño
[EMAIL PROTECTED]

AMD4400 - ASUS48N-E
GeForce7300GT
Kubuntu Edgy

Index: Modules/Platform/Windows-gcc.cmake
===
RCS file: /cvsroot/CMake/CMake/Modules/Platform/Windows-gcc.cmake,v
retrieving revision 1.19
diff -r1.19 Windows-gcc.cmake
55a56,109
 
 FILE(TO_CMAKE_PATH $ENV{PROGRAMFILES} PROGRAMFILES )
 
 #
 # Q:  Should CMAKE_PROJECT_NAME be used instead?
 #
 SET( PROGRAMFILES ${PROGRAMFILES}/${PROJECT_NAME} )
 
 IF(MSYS AND CMAKE_INSTALL_PREFIX STREQUAL ${PROGRAMFILES})
 	# MESSAGE( STATUS Find MSYS ROOT )	
 	#
 	# Attempt to locate MSYS root path by finding sh.exe
 	# in users' path or from environment variable MSYS_ROOT.
 	#
 	IF( NOT MSYS_ROOT )
 	  SET( MSYS_ROOT $ENV{MSYS_ROOT} )
 	ENDIF( NOT MSYS_ROOT )
 
 	IF(NOT MSYS_ROOT)
 	   FIND_PATH( MSYS_ROOT NAMES sh.exe PATHS $ENV{PATH} )
 	   IF( NOT MSYS_ROOT )
 	   MESSAGE( FATAL_ERROR 
 	   CMake could not determine MSYS root.  Please set MSYS_ROOT )
 	   ENDIF( NOT MSYS_ROOT)
 
 	   # MESSAGE( STATUS 1 ${MSYS_ROOT}  )
 
 	   IF( MSYS_ROOT MATCHES .*/local/bin )
 	   	 SET( MSYS_ROOT ${MSYS_ROOT}/.. )
 	   ELSE( MSYS_ROOT MATCHES .*/local/bin )
 		 SET( MSYS_ROOT ${MSYS_ROOT}/../local )
 	   ENDIF( MSYS_ROOT MATCHES .*/local/bin )
 
 	   # MESSAGE( STATUS 2 ${MSYS_ROOT}  )
 
 	   FILE(TO_CMAKE_PATH ${MSYS_ROOT} MSYS_ROOT)
 	   # MESSAGE( STATUS 3 ${MSYS_ROOT}  )
 
 ENDIF(NOT MSYS_ROOT)
 	
 	#
 	# CMake BUG:  IS_DIRECTORY should be used, but that fails with
 	# ../ in path.  
 	# Also, it would be better if we normalized the path
 	# first, but I could not find a function to do so.
 	#
 IF( NOT EXISTS ${MSYS_ROOT} )
 	  MESSAGE( FATAL_ERROR 
 	   CMake uses MSYS root ${MSYS_ROOT}.  But no ${MSYS_ROOT} on disk.  Please create directory or set CMAKE_INSTALL_PREFIX or MSYS_ROOT differently. )
 	ENDIF( NOT EXISTS ${MSYS_ROOT} )
 
 	SET( CMAKE_INSTALL_PREFIX ${MSYS_ROOT} )
 
 ENDIF(MSYS AND CMAKE_INSTALL_PREFIX STREQUAL ${PROGRAMFILES})
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake 2.5 - MinGW fails with NMake Mafiles


[EMAIL PROTECTED] wrote:

On Friday 19 October 2007 13:11, David Cole wrote:

Do not pass -DCMAKE_SYSTEM=Windows-5.1 on the command line. CMake expects
to compute that value itself...

On 10/19/07, Gonzalo Garramuño [EMAIL PROTECTED] wrote:

MinGW CMake also says it supports NMake Makefiles (actually, tons of
formats which sounds super cool).  After compiling a MinGW CMake, I
tried using it to compile cmake again with NMake Makefiles and it also
worked.

But trying a 'NMake Makefiles' build on my project resulted in


cmake ../../../.. -DCMAKE_SYSTEM=Windows-5.1



This is wrong, where did you get this from ? 
If you got it from the cross compiling page, I'll fix that page.




Don't recall.  It used to be the only way to have 2.4.6 Unix Makefiles 
attempt to compile using the microsoft compiler.


Now that the new cmake adds MSYS, MINGW and Unix Makefiles, there seems 
to be no need for it anymore.  Thanks.  It seems like this may fix the 
other issues I was having too.


--
Gonzalo Garramuño
[EMAIL PROTECTED]

AMD4400 - ASUS48N-E
GeForce7300GT
Kubuntu Edgy
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake2.5 - wrong default install location for mingw


Bill Hoffman wrote:
That is not a bug.  MSYS in its charter explicitly says it does not 
want to become a new cygwin.  The tools in msys are available only for 
support of the compiler tool chain. The main goal is to build native 
windows applications with the mingw tool chain.  If you want posix 
applications you should be using cygwin.




Well, yes, the problem with that theory or that take on mingw's charter 
is that:


a) All unix autotools utilities (or other libs like ffmpeg) built under 
mingw/msys will not install in $PROGRAMFILES, which leads to cmake's 
approach being totally backwards with the rest of msys.


The proper approach for mingw with cmake should be to detect the 
environment the user is using.  To me the simplest approach to doing 
that would really be to check if $SHELL is defined.  If it is, it should 
default to a Unix install location of /usr/local (ie MingGW root's 
/usr/local).  If it is not defined, it should default to a windows 
install of $PROGRAMFILES.


b) cygwin's approach is sadly bloated and uses a somewhat inefficient 
approach that also forces you to depend on cygwin.dll and the microsoft 
runtimes (mingw only depends on an outdated microsoft runtime).  That 
makes it not suitable for a lot of stuff (Mind you, I've used cygwin for 
5+ years to have a basic unix shell environment on windows and for that 
I'm eternally thankful but mainly because mingw as a shell environment 
back then was pitiful).  Now the combo of mingw-msys has evolved to be a 
superior solution for me (and I don't need X11 gui tools on windows 
which mingw will probably never provide, which is how I interpret 
mingw's charter).


--
Gonzalo Garramuño
[EMAIL PROTECTED]

AMD4400 - ASUS48N-E
GeForce7300GT
Kubuntu Edgy
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake2.5 - wrong default install location for mingw


Bill Hoffman wrote:

There is no way to tell at cmake time what the user intends to use the 
code for.  If the user of cmake is building a windows app, which is the 
standard use case for MinGW, then it you don't want /usr/local. 


I disagree.  You can infer how MinGW is being used by looking at the 
user's environment.  /usr/local is more tricky but can also be inferred. 
 More below.


The clear goal is to produce native Windows programs, and to support the 
autotools make toolchain with enough programs to run make in order to 
produce native windows applications.   


Okay so far.

What you want to do is extend the 
msys environment with extra POSIX compatible tools.   


No.  I was just trying to compile cmake (or other stuff) under msys and 
have it behave like all other (subset of) autotools libraries or 
executables that can be compiled under such environment.  All of these 
get compiled and installed under MSYS's /usr/local root, not under 
$PROGRAMFILES.


To do that cmake
would have to link to the MSYS run time library in order to understand 
things like sym links and mount points.




AFAIK, no.  If my understanding of MSYS/MinGW is correct, there's no 
extra POSIX compatibility library.  The POSIX compatibility comes from 
the limited POSIX compatibility provided by the win32api and the msvcrt 
DLL.  This is one of the things it distinguishes it from cygwin, where 
the cygwin.dll does indeed try to have a 1-to-1 correspondence with 
POSIX (and some Linux internals too).


--- digression---
Currently, neither cygwin nor mingw support sym links (as they are still 
constrained by what pre-windows vista supports).  Cygwin might support 
mount points other than windows ones (like NFS), but not sure.  MinGW 
certainly does not (only windows A: to Z: drives).
The only magic msys utilities like bash perform is modifying the PATH 
variable for Windows to make /C/ become C:\ and '/' become MSYSROOT\.


---back on topic--
To do what I was suggesting (properly), a MinGW cmake would have to use 
*Windows API* calls to find what its process is child of (like cmd.exe, 
command.com, bash.exe, rxvt.exe, etc.) and then act accordingly to that.


As that may be tricky to do, I suggested a simpler (somewhat hack) 
approach of using the environment variable called SHELL which SHOULD 
be defined under any kind of Unix shell to a valid shell and SHOULD NOT 
be defined under cmd.exe, command.com or if cmake+mingw gets called 
directly by some other windows build environment or utility.  The TERM 
environment variable could also probably be used.


As far as finding the MSYS root, that is indeed tricky as the MSYS.bat 
file does not by default seem to define any environment variable for it.


Currently the MSYS environment is often installed with InnoSetup and a 
registry entry for it exists in:


HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\
MSYS-1.0_is1 or similar

In the case no installer was used or you don't want to tie yourself to 
InnoSetup, it can still be inferred from the user environment.


For one, the PATH variable HAS to contain the unix utilities somewhere. 
 The path to some common unix utility like 'ls' or 'sh' or 'make' could 
be used (which should be $MSYSROOT\bin but could also potentially be 
$MSYSROOT\usr\local\bin).


If addition, you probably still want to have an environment variable or 
CMAKE variable to specify the root of msys in case cmake 'guesses' 
incorrectly.




--
Gonzalo Garramuño
[EMAIL PROTECTED]

AMD4400 - ASUS48N-E
GeForce7300GT
Kubuntu Edgy
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake2.5 - wrong default install location for mingw