Re: [CMake] Question about transitive dependencies
Hello, This discussion is based on my knowledge of the Gnu Compiler Collection. My understanding of the linking process is that B will never link against A, because static libraries don't link against other static libraries. Library B will have unresolved symbols when linking C. You must therefore add a dependency between C and A. Therefore: C links against B and A B doesn't link against anything B needs the header information for the functions of A. I never use shared libraries, but I think the dynamic linker may need to resolve a dynamic B against a dynamic A. Juan On Thu, Dec 4, 2008 at 3:25 PM, Robert Dailey [EMAIL PROTECTED] wrote: Hi, Currently I have 3 projects named A, B, and C. A and B are both static libraries, and C is an executable. B depends on A, and C depends on B via add_dependencies(). When I generate a visual studio 9 project from this setup, how will the libraries be linked? The way I want this to work is for C to link against both A and B, and B will not link against A (Since B's dependencies should transfer to C). Is there a way to accomplish this behavior? I want to avoid using target_link_libraries for the most part because it's redundant. I'm already specifying B as a dependency of C through add_dependency(), why should I have to list B's static library file as a dependency of C's executable? Can't CMake pull this information from the call to add_dependency()? ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] 64bit programming
Usually, that should never be a problem as casting from long to a pointer and back is really good coding style in modern C (about the same as not differing between function/code pointer and data pointers). I think that size_t would be more appropriate than a signed long. If you need sign, than perhaps ptrdiff_t. Juan On Mon, Aug 25, 2008 at 11:09 AM, Matthew Woehlke [EMAIL PROTECTED] wrote: Hendrik Sattler wrote: Am Samstag, 23. August 2008 02:34:35 schrieb Matthew Woehlke: Don't make assumptions about sizeof(long) or sizeof(void*)... not even that they are the same (Microsoft, in their infinite wisdom, decided - as usual - to be different from everyone else and adopt a P64 model, rather than LP64 used by *everyone* else). That's the big thing. I don't know about kitware libraries, but I wouldn't expect much in the way of gotchas regarding 64-bit builds and cmake... at least, not on non-Windows platforms :-). Usually, that should never be a problem as casting from long to a pointer and back is really good coding style in modern C (about the same as not differing between function/code pointer and data pointers). Unless I misunderstood the above, you're missing really good coding style in modern C **unless you ever want to support Windows**... -- Matthew Person A: It's an ISO standard. Person B: ...And that means what? --mal (http://theangryadmin.blogspot.com/2008/04/future.html) ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Make with dos paths
I'm going to have to follow up on this a little further down the road. Thanks for the interesting links. It appears that package management is a big issue for installing mingw or gnuwin32. Also MSYS apparently requires a lot of work to not crash on Windows Vista 64. Thanks, Juan On Thu, Jun 12, 2008 at 2:53 AM, Eric Noulard [EMAIL PROTECTED] wrote: 2008/6/12 Alin M Elena [EMAIL PROTECTED]: HI Juan It may be easier than you think to port on Windows. Have a look at these links http://unxutils.sourceforge.net/ plus http://www.microsoft.com/downloads/details.aspx?FamilyID=60deac2b-975b-41e6-9fa0-c2fd6aa6bc89displaylang=en I would add this: http://gnuwin32.sourceforge.net/ I personnally use Gnuwin32 flex and bison + MinGW + CMake for native win32 port of a unix-developped tool with success. -- Erk ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Make with dos paths
Thanks for for the link. I'm going to give up on a windows port for a while. There are too many issues for me to figure out concerning flex with dos paths, bison with dos paths, my custom build utilities with dos paths, unicode support, etc. I guess it is not possible for the cygwin version of the compiler to know that cl.exe needs a dos path, and everything else does not? Regards, Juan On Tue, Jun 10, 2008 at 10:49 AM, Bill Hoffman [EMAIL PROTECTED] wrote: John Doe wrote: I am trying to use the unix makefiles generator with the windows version of cmake. Unfortunately the make packaged with cygwin does not like the ':' in the dos path name. What version of make should I use? Geometry/CMakeFiles/geom.dir/build.make:53: *** target pattern contains no `%'. Stop. Replace the cygwin make with this one: http://www.cmake.org/files/cygwin/make.exe -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Make with dos paths
I am trying to use the unix makefiles generator with the windows version of cmake. Unfortunately the make packaged with cygwin does not like the ':' in the dos path name. What version of make should I use? Geometry/CMakeFiles/geom.dir/build.make:53: *** target pattern contains no `%'. Stop. Thanks, Juan ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to set up Cygwin + CMake + GNU Makefiles + cl.exe correctly?
I was able to setup the compiler using a file similar to Bill's.
Unfortunately it appears that cygwin cmake is passing the unix paths
to cl.exe on my Windows Vista 64 system.
What command line options for cmake will allow the compiler tests to
pass. I tried -DWIN32=1 and -DCMAKE_CL_64=1, but neither seems to
work.
Thanks in advance.
Juan
On Fri, May 30, 2008 at 10:38 AM, Bill Hoffman [EMAIL PROTECTED] wrote:
Stefan Buschmann wrote:
Hi all!
I'm trying to build my project on Windows using GNU Makefiles and cl.exe
under Cygwin. I'm using CMake-2.6-patch 0 and Microsoft Visual Studio 2008
Professional.
Here is my setup:
export CC=cl
export CXX=cl
export INCLUDE=C:\Program Files\Microsoft Visual Studio
9.0\VC\ATLMFC\INCLUDE;C:\Program Files\Microsoft Visual Studio
9.0\VC\INCLUDE;C:\Program Files\\Microsoft SDKs\Windows\v6.0A\include;
export LIB=C:\Program Files\Microsoft Visual Studio
9.0\VC\ATLMFC\LIB;C:\Program Files\Microsoft Visual Studio
9.0\VC\LIB;C:\Program Files\\Microsoft SDKs\Windows\v6.0A\lib;
export
LIBPATH=C:\WINDOWS\Microsoft.NET\Framework\v3.5;C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727;C:\Program
Files\Microsoft Visual Studio 9.0\VC\ATLMFC\LIB;C:\Program Files\Microsoft
Visual Studio 9.0\VC\LIB;
export PATH=/cygdrive/c/Program\ Files/Microsoft\ Visual\ Studio\
9.0/Common7/IDE:/cygdrive/c/Program\ Files/Microsoft\ Visual\ Studio\
9.0/VC/BIN:/cygdrive/c/Program\ Files/Microsoft\ Visual\ Studio\
9.0/Common7/Tools:/cygdrive/c/WINDOWS/Microsoft.NET/Framework/v3.5:/cygdrive/c/WINDOWS/Microsoft.NET/Framework/v2.0.50727:/cygdrive/c/Program\
Files/Microsoft\ Visual\ Studio\ 9.0/VC/VCPackages:/cygdrive/c/Program\
Files//Microsoft\
SDKs/Windows/v6.0A/bin:/cygdrive/c/emacs/emacs-21.3/bin/:${PATH}
Works fine.
-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How To Question
On Tue, May 13, 2008 at 3:27 PM, Richard Wackerbarth [EMAIL PROTECTED] wrote: Juan, Thanks for your suggestions. Your ADD_TEST suggestion is just a (desirable) wrapping of the fundamental question which was Are there any standard CMake variables that can be tested to differentiate various machine capabilities? Perhaps you can do something like this: EXEC_PROGRAM(uname ARGS -m OUTPUT_VARIABLE ARCH) Where you use uname with the appropriate option or create your own exec to come up with a version string. As to the Test A Test B, we need to see on the dashboard that Test A passed (with its accompanying metrics) and that Test B failed. Any attempt to have the combined test reported as one entry will suppress valuable information. Richard On May 13, 2008, at 3:12 PM, John Doe wrote: On Tue, May 13, 2008 at 3:00 PM, Richard Wackerbarth [EMAIL PROTECTED] wrote: I'm still trying to figure out how to handle the following two situations (simplified): When we run the tests for our Nightly Dashboard, in addition to a number of other tests, consider Test A and Test B. If Test A fails, then I don't even want to attempt to run Test B. You can make them part of the same test and then run them as: testa.exe testb.exe so that the second test won't run and they both show up under one test name as failing. You can also wrap testb in a script so that it tests to see whether or not the results of testa are available or even that your machine has the appropriate resources.. Perhaps you can script ADD_TEST in your CMakeLists if the test doesn't apply to your platform. Regards, Juan The program is a complex one that can run on a wide range of hardware. It can handle both easy data sets and hard ones. The hard ones push system resources, in terms of both cpu cycles and memory, and exercise parts of the program that are not necessary for the easy data sets. Although it would try, we know, in advance, that some of the older hardware is not capable in handling the more difficult data sets. The test will fail, either because of memory or time constraints. Therefore, I would like to avoid even attempting to run some of the tests on installations that have older CPUs or smaller memory. Are there any standard CMake variables that can be tested to differentiate various machine capabilities? Is there any interest in establishing some? ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to generate a source file with unpredictable dependency
The percent meter has never been 100% accurate for me, especially when I use make -j2. It is kind of a good guess and gives you something to look at when your are waiting for the compile. Juan On Tue, May 13, 2008 at 6:11 PM, jlh [EMAIL PROTECTED] wrote: jlh wrote: $ make [ 0%] Checking version.cpp [ 3%] Built target Version [103%] Built target project Seems like something is off by one, probably version.cpp gets counted in one place but not in another. Is this rather something still wrong with my CMakeList.txt or a bug in cmake? jlh ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Coverage tests with gcov under Linux
in tcsh: setenv LC_ALL POSIX or if you need utf-8 setenv LC_ALL en_US.UTF-8 In bash: export LC_ALL=en_US.UTF-8 Regards, Juan On Fri, May 9, 2008 at 12:40 PM, Bill Hoffman [EMAIL PROTECTED] wrote: Judicaël Bedouet wrote: I have just tested with an other machine (a Fedora core 6). It's better but it's a tricky thing : gcc version is 4.1 (g++ (GCC) 4.1.2 20070626 (Red Hat 4.1.2-13)). First machine is an XUbuntu. The file main.cxx is yet marked as UNTESTED under CDash. So, I tried with CMake 2.4-6, which is provided by Fedora, and with this version, I can see the line which is not covered. As soon as I can, I will download the lastest CVS version to see if the UNTESTED problem is resolved but I can't understand why under XUbuntu I can't have coverage results. The problem is here: Unknown line: [Lignes exécutées: 57.14% de 21] Unknown line: [File « /usr/include/c++/4.2/iostream »] Unknown line: [Lignes exécutées: 100.00% de 1] Unknown line: [File « /home//cvs/xxx/Key.h »] Unknown line: [Lignes exécutées: 100.00% de 4] Looks like it is the French that is messing things up... CTest has some regex stuff to parse the output of gcov: std::string st2gcovOutputRex1 = ^File *[`'](.*)'$; std::string st2gcovOutputRex2 = Lines executed: *[0-9]+\\.[0-9]+% of [0-9]+$; ... If none of those regex expressions are matched it does this: cmCTestLog(this-CTest, ERROR_MESSAGE, Unknown line: [ line-c_str() ] std::endl); cont-Error ++; Your gcov has be internationalized and is not talking French, CTest does not speak French. Is there an environment variable that can turn that off? -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Coverage tests with gcov under Linux
Since this is the fault of cmake, you should perhaps have it set the
proper locale when the program first begins. I have never done this,
but a google search reveals stuff like:
std::setlocale(LC_ALL, En_US);
std::fscanf(priceFile,%lf,price);
// convert $ to DM according to the current exchange rate
std::setlocale(LC_ALL,De_DE);
std::strfmon(buf,SZ,%n,price);
std::fprintf(invoiceFile,%s,buf);
for C
or for C++
priceFile.imbue(std::locale(En_US));
invoiceFile.imbue(std::locale(De_DE));
moneytype price;
while ( ... ) // processing the German invoice
{
priceFile price;
// convert $ to DM according to the current exchange rate
invoiceFile price;
}
See http://stdcxx.apache.org/doc/stdlibug/24-3.html for an example.
Regards,
Juan
On Fri, May 9, 2008 at 5:23 PM, Alan W. Irwin [EMAIL PROTECTED] wrote:
On 2008-05-09 16:56-0500 John Doe wrote:
in tcsh:
setenv LC_ALL POSIX
or if you need utf-8
setenv LC_ALL en_US.UTF-8
In bash:
export LC_ALL=en_US.UTF-8
That should be a good workaround, but ideally cmake should avoid locale
issues like this one if at all possible since internationalization is
becoming more and more ubiquitous on all platforms.
So, Bill, is there some good alternative to parsing for the locale-dependent
Lines executed string or are you stuck with it?
Alan
__
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__
Linux-powered Science
__
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Coverage tests with gcov under Linux
I don't know how your program works or how it is exec'ing other software. However, it should ensure that the proper environment is set before these other programs are executed. Using setlocale may result in whatever system functions and whatever regex functions you are using to at least read the input in a manner that you are expecting. Perhaps setlocale is not the appropriate function, but cmake needs to ensure whatever program's output being parsed is in the right language. Good luck, Juan On Fri, May 9, 2008 at 8:54 PM, Bill Hoffman [EMAIL PROTECTED] wrote: John Doe wrote: Since this is the fault of cmake, you should perhaps have it set the proper locale when the program first begins. I have never done this, but a google search reveals stuff like: std::setlocale(LC_ALL, En_US); std::fscanf(priceFile,%lf,price); // convert $ to DM according to the current exchange rate std::setlocale(LC_ALL,De_DE); std::strfmon(buf,SZ,%n,price); std::fprintf(invoiceFile,%s,buf); I don't see how that would help me at all? CMake is parsing the output of another program. If the LC_ALL works, the thing to do would be to set LC_ALL to POSIX before ctest runs gcov. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Compiling x86 executable on amd64
Mathieu, It is perfectly ok to redistribute libstdc++. You put it in your directory tree, not in the standard system location. Setting LD_LIBRARY_PATH to the directory of your libstdc++ allows only applications started in that shell environment to find it. You can use a wrapper script to set this environment variable and exec your binary. This is the same stuff that firefox has been doing for years for all of their dependencies. Use ldd on your binary to determine which shared libraries you link against. Use ldd on the shared libraries to determine the shared libraries they link against. Make sure that the appropriate libraries are redistributed with your app. Of course certain one's cannot be redistributed since they are directly linked against your particular kernel and would be useless to your customer. Statically link as much as you can. The p4 client works fine on my gentoo box. So does the intel compiler the last time I checked. See what libraries they redistribute. To get around this issue, many vendors say which distributions are supported by their application so they don't have to build and support every linux distribution out there. Creating a chroot jail (or using vmware) are other alternatives. How is trying to help you redistribute linux applications make me a Microsoft spy? How is insulting your customers by saying they don't know how to compile things not make you a Microsoft spy? The hard reality is that it isn't easy to guarantee compatibility across all of your applications. How is g++ 4.3 that much of a step up from g++ 3.4? Why not use the intel compiler or the one from the portland group? Good luck, Juan On Fri, May 2, 2008 at 1:50 PM, Mathieu Malaterre [EMAIL PROTECTED] wrote: John, On Fri, May 2, 2008 at 8:11 PM, John Doe [EMAIL PROTECTED] wrote: On Fri, May 2, 2008 at 12:54 PM, Mathieu Malaterre [EMAIL PROTECTED] wrote: Hi there, Not really a cmake issue, but people maybe know the answer here... 1. I am trying to generate package for x86 linux platform, since I have all the multilib (lib32 thingy) I thought this should be trivial to cross compile for this target (this is not a true cross compilation as the target can be run on the host sytem). 2. What are the gcc flags to use the older glibc symbol so that I don't get report of people telling: I cannot run your executable it says: libstdc++.so.6: version `GLIBCXX_3.4.9' not found As far as I know you can't. =O ... of course you can. How do you think cmake binaries is working on all kind of linux system, and even on my amd64 system via the i32 layer. Options: 1. Give them a copy of your libstdc++.so.6 (find with libstdc++.so.6) and use LD_LIBRARY_PATH or LD_PRELOAD to tell where it is. I am talking about packaging here. Shipping a libstdc++.6 that could potentially override my user libstdc++ is clearly a real bad *bad* idea ! 2. Tell them to use the same os as you. ...seriously. Are you some kind of Microsoft spy ? What I am asking is trivial stuff, just cannot find the documentation. One straight solution is get an old linux box myself and compile my package on it... I do not have a spare box for that, nor do I want to do that. 3. Create some sort of chroot system to replicate all of their system libraries. I was thinking that maybe runing vmware in XEN, in another system emulation could be even better ... 4. Give them the source code. make package != make package_source. I know how to build source package. But you cannot seriously ask a simple user to build an app like paraview to open a vtk file and then never use paraview again ... If I cannot get anything more usefull, I'll switch to using gcc 3.4.0 which is the oldest AFAIK wich implement CXX=ABI 2 for g++. I still prefer my g++4.3 (better compilation time, better optimization...). -- Mathieu ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] prefer static to dynamic library on linux
Hello, I just started using ubuntu linux and it is a pleasure to see that they provide both static and shared versions of libtcl8.4. Is there a way to tell cmake to prefer the static version of this library, even if they are in the same directory, /usr/lib. Thanks, Juan ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] problem creating a library on mac
Did you run nm on the library containing these symbols to verify they exist?
_tetra_zone_copy_
_xyz_vertex_copy_
The trailing underscore is reminiscent of a Fortran compiler. Are you using
the write convention when calling these functions from C code? On Linux,
you would call the Fortran function foo as foo_.
Should you be linking against libm, if you are getting the same symbols from
libimf.a?
ld: warning multiple definitions of symbol _modf
/opt/intel/cc/10.0.016/lib/libimf.a(modf_stub.o) definition of _modf in
section (__TEXT,__text)
/usr/lib/gcc/i686-apple-darwin8/4.0.1/../../..//libm.dylib(xmm_floor.o)
definition of _modf
Regards,
Juan
On 9/27/07, Marie-Christine Vallet [EMAIL PROTECTED] wrote:
Mike Jackson wrote:
Marie,
Use the following in your CMakeLists.txt file, generally near the
top just after you define the PROJECT (... )
SET (LIBRARY_OUTPUT_PATH ${PROJECT_BINARY_DIR}/Bin CACHE INTERNAL
For libraries.)
SET (EXECUTABLE_OUTPUT_PATH ${PROJECT_BINARY_DIR}/Bin CACHE INTERNAL
For executables.)
done
This will put all the compiled libraries and executables into the same
bin directory.
Also, I think you may be missing a key philosophy of CMake which is
Out of Source builds. In your project folder create a new folder
called Build. Then from the a terminal run the following commands:
cd Build
cmake ../
make
thanks, I did not know that
Also, on to the actual problem, can you post the actual linker
command? Run make VERBOSE=1 and post the output.
I did the modifications you suggested, but it still does not work. For
the include directory, I had to keep
these lines :
*--
SET(SKINMESH_INCLUDE_DIR
${CMAKE_SOURCE_DIR}/skinmesh
)
SET(INCLUDE_DIR
${INCLUDE_DIR}
${SKINMESH_INCLUDE_DIR}
)
SET(INCLUDE_DIR
${INCLUDE_DIR}
${SKINMESH_INCLUDE_DIR}
)
*--
even though I did made the modification suggested in cmake file the
source directory otherwise, it was not working
Here is my linker command:
Linking CXX executable ../bin/mdi
cd /Users/program/qtskinmesh/build/mdi /usr/local/bin/cmake -P
CMakeFiles/mdi.dir/cmake_clean_target.cmake
cd /Users/program/qtskinmesh/build/mdi
/opt/intel/cc/10.0.016/bin/icpc -O3 -mp1 -Kc++ -Dintel
-headerpad_max_install_names -bind_at_load CMakeFiles/mdi.dir/main.o
CMakeFiles/mdi.dir/csbdmainwindow.o CMakeFiles/mdi.dir/csbdmdichild.o
CMakeFiles/mdi.dir/moc_csbdmainwindow.o
CMakeFiles/mdi.dir/moc_csbdmdichild.o
CMakeFiles/mdi.dir/qrc_qt4skinmesh.o -o ../bin/mdi
-L/Users/program/qtskinmesh/build/skinmesh
-L/Users/program/qtskinmesh/build/bin -L/usr/local/lib
-L/usr/X11R6/lib -L/opt/intel/fc/10.0.016/lib -F/Library/Frameworks
-framework QtGui -framework Carbon -framework QuickTime -framework QtXml
-framework QtCore -lz -framework ApplicationServices -framework QtOpenGL
-lQGLViewer -lgmp -lm -lGL -lGLU -lirc -limf -lifcore -lskinmesh -lgmp -lm
-lGL -lGLU -lirc -limf -lifcore
ld: warning multiple definitions of symbol _modf
/opt/intel/cc/10.0.016/lib/libimf.a(modf_stub.o) definition of _modf in
section (__TEXT,__text)
/usr/lib/gcc/i686-apple-darwin8/4.0.1/../../..//libm.dylib(xmm_floor.o)
definition of _modf
ld: Undefined symbols:
_tetra_zone_copy_
_xyz_vertex_copy_
and my Undefined symbols are all part of my newly created library
skinmesh. What suprrisses me the most is that all that works on fedora
core 6
Thanks again,
Marie
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Compiling fortran
While the cmake man page does not document the proper capitalization of Fortran for creating a fortran based project, I am now at the point the compilation does not work for another reason. Does anyone have an idea what this means? Clearing dependencies in CMakeFiles/pisces.dir/depend.make. Clearing dependencies in CMakeFiles/pisces.dir/depend.internal. /usr/bin/cmake -E cmake_progress_start /home/anon/svn/svn_repository/relB.9009/pisces/9009/src/CMakeFiles 50 make -f CMakeFiles/Makefile2 all make[1]: Entering directory `/home/anon/svn/svn_repository/relB.9009/pisces/9009/src' make -f CMakeFiles/pisces.dir/build.make CMakeFiles/pisces.dir/depend make[2]: Entering directory `/home/anon/svn/svn_repository/relB.9009/pisces/9009/src' Scanning dependencies of target pisces cd /home/anon/svn/svn_repository/relB.9009/pisces/9009/src /usr/bin/cmake -E cmake_depends Unix Makefiles /home/anon/svn/svn_repository/relB.9009/pisces/9009/src /home/anon/svn/svn_repository/relB.9009/pisces/9009/src /home/anon/svn/svn_repository/relB.9009/pisces/9009/src /home/anon/svn/svn_repository/relB.9009/pisces/9009/src /home/anon/svn/svn_repository/relB.9009/pisces/9009/src/CMakeFiles/pisces.dir/DependInfo.cmake make[2]: Leaving directory `/home/anon/svn/svn_repository/relB.9009/pisces/9009/src' make -f CMakeFiles/pisces.dir/build.make CMakeFiles/pisces.dir/requires make[2]: Entering directory `/home/anon/svn/svn_repository/relB.9009/pisces/9009/src' make[2]: *** No rule to make target `new.mod.proxy', needed by `CMakeFiles/pisces.dir/filopncls.o.requires'. Stop. make[2]: Leaving directory `/home/anon/svn/svn_repository/relB.9009/pisces/9009/src' make[1]: *** [CMakeFiles/pisces.dir/all] Error 2 make[1]: Leaving directory `/home/anon/svn/svn_repository/relB.9009/pisces/9009/src' Thanks, Juan ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
