Re: [CMake] need two compilation to achieve success

2009-06-01 Thread e...@cs.bgu.ac.il

On Mon 01 Jun 20:56 2009 Bill Hoffman wrote:
> e...@cs.bgu.ac.il wrote:
> > On Mon 01 Jun 15:28 2009 Bill Hoffman wrote:
> >> e...@cs.bgu.ac.il wrote:
> >>> On Mon 01 Jun 8:18 2009 Tyler Roscoe wrote:
> >>> thanks for the tip, it solved the issue.
> >>>
> >>>
> >> I am glad that worked for you but something else is wrong...  How are 
> >> you linking bin/libs/libAgathaUtils.so' to `bin/AgathaHud' ?  You should 
> >> have something like:
> >>
> >> target_link_libraries(AgathaHud AgathaUtils)
> >>
> >> That should add the dependency for you.   Do you have that?
> >>
> >> -Bill
> >>
> > 
> > I have this:
> > TARGET_LINK_LIBRARIES(AgathaHud ${LIBRARY_OUTPUT_PATH}/libAgathaUtils.so 
> > ${LIBRARY_OUTPUT_PATH}/libAgathaEngine.so
> > ${LIBRARY_OUTPUT_PATH}/libAgathaThreads.so
> > cv
> > PocoXML
> > PocoFoundation
> > AR
> > ARMulti
> > ARvideo)
> > 
> > 
> 
> OK, that is not correct.  For targets that CMake builds, you can just 
> use the target name.  What you have now will only work on some systems 
> and not work if you use OUTPUT_NAME or other properties on those 
> libraries.
> 
> You want:
> target_link_libraries(AgathaHud AgathaUtils AgathaEntine AgathaThreads)
> 
> That is assuming that AgathaUtils AgathaEntine AgathaThreads are all 
> built in the same project by CMake.
> 
> -Bill
> 

yes they are built in the same project.
changing you your suggestions results in two new problems:
1) removing ${LIBRARY_OUTPUT_PATH} results in 
"/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/../../../../x86_64-pc-linux-gnu/bin/ld: 
cannot find -lAgathaUtils" error, the structure of the output dir is bin for 
the binary and bin/libs for the libs.
2) with ${LIBRARY_OUTPUT_PATH}, compilation fails due to unknown reference to 
all vars and functions that are part of the external libs.
I've encountered this before and that was the only way that I've found to solve 
it.




___
Powered by www.kitware.com

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

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

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


Re: [CMake] win32 and x64 in the same generator?

2009-06-01 Thread Mike Jackson
On Mon, Jun 1, 2009 at 10:36 PM, Philip Lowman  wrote:
> On Mon, Jun 1, 2009 at 6:29 PM, Tyler Roscoe  wrote:
>>
>> What are the pitfalls or difficulties in supporting this sort of
>> "cross-compiling" in Visual Studio?
>
> Two things come to mind:
>
> 1. find_library() (i.e. dependencies).. How would you pick 64-bit vs.
> 32-bit?
> 2. When compile tests are run (e.g. sizeof(void*) ).  Which compiler would
> be used, 32-bit or 64-bit?
>
> --
> Philip Lowman
>
Those same problems are all in the Xcode generator also as one can
specify up to 4 archs on OS X to compile for.

Mike J.
___
Powered by www.kitware.com

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

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

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


Re: [CMake] set_property() scope qualifier question...

2009-06-01 Thread Philip Lowman
On Mon, Jun 1, 2009 at 2:12 PM, Sean Chittenden  wrote:

> Ideally I'd like to see cmake(1) be able to issue the following commands:
>>>
>>> // Create foo_test
>>> gcc -o foo.o -c foo.c -DTESTING
>>> gcc -o foo_test foo.o
>>>
>>> // Create bar_test
>>> gcc -o foo.o -c foo.c
>>> gcc -o bar.o -c bar.c -DTESTING
>>> gcc -o bar_test foo.o bar.o
>>>
>>>
>>> That help clarify?  set_target_property() still defines TESTING for both
>>> foo.c and bar.c and the bar_test case would break.  Ideally I'd like to set
>>> a source property in the bar_test case, but don't know how to do that.  I
>>> thought the scope property would do it.  Can I somehow finagle this using an
>>> if() ?
>>>
>>
>> Not that I know of.
>>
>
> Drat.  Well...  guess this is a feature request then: being able to set
> properties on a per source and per target (or test).  :~]
>

File the feature request in the CMake bugtracker if you like.
http://public.kitware.com/Bug/my_view_page.php

I think what you're really asking for is the ability to set the
COMPILE_FLAGS source file property on a per-target basis.

-- 
Philip Lowman
___
Powered by www.kitware.com

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

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

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

Re: [CMake] win32 and x64 in the same generator?

2009-06-01 Thread Philip Lowman
On Mon, Jun 1, 2009 at 6:29 PM, Tyler Roscoe  wrote:

> What are the pitfalls or difficulties in supporting this sort of
> "cross-compiling" in Visual Studio?


Two things come to mind:

1. find_library() (i.e. dependencies).. How would you pick 64-bit vs.
32-bit?
2. When compile tests are run (e.g. sizeof(void*) ).  Which compiler would
be used, 32-bit or 64-bit?

-- 
Philip Lowman
___
Powered by www.kitware.com

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

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

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

[CMake] win32 and x64 in the same generator?

2009-06-01 Thread Tyler Roscoe
Our developers are used to a single .vcproj that knows how to build both
32-bit and 64-bit versions of libraries. Under CMake, 32-bit and 64-bit
are considered separate platforms with separate generators and requiring
separate binary directories.

Conceptually and as a build engineer, this makes more sense to me.
Pragmatically and as a developer, it just means extra hoops to jump
through.

This topic has been discussed in passing on the list: 

http://www.cmake.org/pipermail/cmake/2007-February/012982.html
http://www.cmake.org/pipermail/cmake/2007-September/016630.html

To answer Bill's question from that first link, I don't think CMake
would need to do anything special. Users need to have the PlatformSDK
for 64-bit installed (or something like that), but it looks like the
.vcproj just has an extra Platform:






and then some extra Configurations:






What are the pitfalls or difficulties in supporting this sort of
"cross-compiling" in Visual Studio?

Thanks,
tyler
___
Powered by www.kitware.com

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

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

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


Re: [CMake] How to guarntee the sequence of build if no target can be used

2009-06-01 Thread Dong Tiger
Thanks. It works.

2009/6/1 Alexander Neundorf 

> On Monday 01 June 2009, Dong Tiger wrote:
> > 2009/5/29 Alexander Neundorf 
> >
> > > On Thursday 28 May 2009, idlecat...@gmail.com wrote:
> > > > Hi,
> > > >
> > > > This situation is:
> > > >
> > > > foo.h is generated from foo.x. And foo.h is included by bar.h. And
> then
> > > > bar.h is included by a lot of c files. So actually every c files
> > >
> > > including
> > >
> > > > bar.h depends on foo.h.
> > > > But the file number is so big that I don't want to add dependency for
> > >
> > > each
> > >
> > > > one.
> > > >
> > > > How can I specify foo.x is generated before all the c files being
> > >
> > > compiled?
> > >
> > > > It seems add_custom_target works but it will regenerate foo.h every
> > > > time even the foo.x is not modified.
> > >
> > > You should use
> > > add_custom_command(OUTPUT /foo.h
> > >   ... )
> > >
> > > and then list that generated file as a source file for your target:
> > >
> > > add_library(blub /foo.h foo.c bar.c ...)
> >
> > I know by this way, if foo.h is changed, blub will be rebuilt. But what I
> > need is foo.h is guaranteed to be up to date before foo.o is built.  I am
> > not sure if this command is relevant to this. Will cmake try to make sure
> > all the src files are up to date before compiling any .c files?
>
> Yes.
>
> > > This should make sure that everything is up to date.
> > >
> > > The header-file dependency scanning does in general not work for
> > > generated files, you need to list the generated file as source file for
> > > the targets which need it.
> >
> > Another problem is that I am trying to avoid adding dependencies for
> these
> > generated files manually because in my project, there are many generated
> > head files and quite a few .c files including them. I just want to make
> > sure the head files are generated before any .c compilation.
> > ADD_CUSTOM_TARGET can do this but it will regenerate the head files even
> > they are up-to-date.
>
> There should be no need to do this if you use add_custom_command()
>
> Alex
>
___
Powered by www.kitware.com

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

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

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

Re: [CMake] CTest with multiple directories: problem with absolute paths

2009-06-01 Thread Bill V
>> I haven't tested this yet with a cmake build tree that has relative
>> entries in the CTestTest.cmake files so there may be issues but for
>> now this looks good enough to keep us going until a real solution is
>> in place.
>>
>
> Can you open a bug for this, and include a small complete example that shows 
> the problem?

I've submitted issue 9090 which describes what we're seeing and a
potential fix.We can put together an archive of the sample build
files if that would help with the reproduction.

http://public.kitware.com/Bug/view.php?id=9090

Bill V.
___
Powered by www.kitware.com

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

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

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


Re: [CMake] Passing multiple arguments to add_custom_command

2009-06-01 Thread Tyler Roscoe
On Mon, Jun 01, 2009 at 04:31:33PM -0400, Iman Brouwer wrote:
> #Add the source files
> FOREACH( cpp ${sources } )
> SET( arguments "${arguments} ${cpp}" )
> ENDFOREACH( cpp )
> add_custom_command( TARGET test COMMAND "script.py" "${arguments}" )

I think that will work if you get rid of the "" around ${arguments}.

You also might want to look at the VERBATIM parameter to
add_custom_command().

tyler
___
Powered by www.kitware.com

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

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

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


[CMake] Passing multiple arguments to add_custom_command

2009-06-01 Thread Iman Brouwer
Hello,

I'm trying to pass multiple arguments to a python script. The last arguments
are file names that are already in a cmake list (semicolon seperated
string).
Is it possible to pass the elements in this list to the python script as
separate arguments?

--
SET( sources s1.cpp s2.cpp s3.cpp )
SET( arguments "-c 2" )

#Add the source files
FOREACH( cpp ${sources } )
SET( arguments "${arguments} ${cpp}" )
ENDFOREACH( cpp )
add_custom_command( TARGET test COMMAND "script.py" "${arguments}" )


The above cmake script will call script.py with the "-c 2 s1.cpp s2.cpp
s3.cpp" as a single argument instead of 5 individual arguments

Manually typing them out as individual strings does solve the problem but
would be impractical:
add_custom_command( TARGET test COMMAND "script.py" "-c" "5" "s1.cpp"
"s2.cpp" )

Any help would be greatly appreciated,

Iman
___
Powered by www.kitware.com

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

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

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

Re: [CMake] How to guarntee the sequence of build if no target can be used

2009-06-01 Thread Alexander Neundorf
On Monday 01 June 2009, Dong Tiger wrote:
> 2009/5/29 Alexander Neundorf 
>
> > On Thursday 28 May 2009, idlecat...@gmail.com wrote:
> > > Hi,
> > >
> > > This situation is:
> > >
> > > foo.h is generated from foo.x. And foo.h is included by bar.h. And then
> > > bar.h is included by a lot of c files. So actually every c files
> >
> > including
> >
> > > bar.h depends on foo.h.
> > > But the file number is so big that I don't want to add dependency for
> >
> > each
> >
> > > one.
> > >
> > > How can I specify foo.x is generated before all the c files being
> >
> > compiled?
> >
> > > It seems add_custom_target works but it will regenerate foo.h every
> > > time even the foo.x is not modified.
> >
> > You should use
> > add_custom_command(OUTPUT /foo.h
> >   ... )
> >
> > and then list that generated file as a source file for your target:
> >
> > add_library(blub /foo.h foo.c bar.c ...)
>
> I know by this way, if foo.h is changed, blub will be rebuilt. But what I
> need is foo.h is guaranteed to be up to date before foo.o is built.  I am
> not sure if this command is relevant to this. Will cmake try to make sure
> all the src files are up to date before compiling any .c files?

Yes.

> > This should make sure that everything is up to date.
> >
> > The header-file dependency scanning does in general not work for
> > generated files, you need to list the generated file as source file for
> > the targets which need it.
>
> Another problem is that I am trying to avoid adding dependencies for these
> generated files manually because in my project, there are many generated
> head files and quite a few .c files including them. I just want to make
> sure the head files are generated before any .c compilation.
> ADD_CUSTOM_TARGET can do this but it will regenerate the head files even
> they are up-to-date.

There should be no need to do this if you use add_custom_command()

Alex
___
Powered by www.kitware.com

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

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

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


Re: [CMake] set_property() scope qualifier question...

2009-06-01 Thread Sean Chittenden
Ideally I'd like to see cmake(1) be able to issue the following  
commands:


// Create foo_test
gcc -o foo.o -c foo.c -DTESTING
gcc -o foo_test foo.o

// Create bar_test
gcc -o foo.o -c foo.c
gcc -o bar.o -c bar.c -DTESTING
gcc -o bar_test foo.o bar.o


That help clarify?  set_target_property() still defines TESTING for  
both foo.c and bar.c and the bar_test case would break.  Ideally  
I'd like to set a source property in the bar_test case, but don't  
know how to do that.  I thought the scope property would do it.   
Can I somehow finagle this using an if() ?


Not that I know of.


Drat.  Well...  guess this is a feature request then: being able to  
set properties on a per source and per target (or test).  :~]



How about
set_property(TARGET foo_test APPEND PROPERTY COMPILE_FLAGS "- 
DTESTING_FOO")
set_property(TARGET bar_test APPEND PROPERTY COMPILE_FLAGS "- 
DTESTING_BAR")



My use of patch(1) does exactly that, let's me use -DTESTING_FOO and - 
DTESTING_BAR.  I find that to be less than ideal and thought that I  
was missing something or wasn't aware of a trick using if() or some  
other something.


Thanks in advance and thanks for cmake(1).  I'm very happy not using  
auto* anymore (though I wish there was a "create an sh(1) script mode  
for source distributions" when distributing source tar files).  -sc



--
Sean Chittenden
s...@chittenden.org



___
Powered by www.kitware.com

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

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

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


Re: [CMake] need two compilation to achieve success

2009-06-01 Thread Bill Hoffman

e...@cs.bgu.ac.il wrote:

On Mon 01 Jun 15:28 2009 Bill Hoffman wrote:

e...@cs.bgu.ac.il wrote:

On Mon 01 Jun 8:18 2009 Tyler Roscoe wrote:
thanks for the tip, it solved the issue.


I am glad that worked for you but something else is wrong...  How are 
you linking bin/libs/libAgathaUtils.so' to `bin/AgathaHud' ?  You should 
have something like:


target_link_libraries(AgathaHud AgathaUtils)

That should add the dependency for you.   Do you have that?

-Bill



I have this:
TARGET_LINK_LIBRARIES(AgathaHud ${LIBRARY_OUTPUT_PATH}/libAgathaUtils.so 
${LIBRARY_OUTPUT_PATH}/libAgathaEngine.so

${LIBRARY_OUTPUT_PATH}/libAgathaThreads.so
cv
PocoXML
PocoFoundation
AR
ARMulti
ARvideo)




OK, that is not correct.  For targets that CMake builds, you can just 
use the target name.  What you have now will only work on some systems 
and not work if you use OUTPUT_NAME or other properties on those 
libraries.


You want:
target_link_libraries(AgathaHud AgathaUtils AgathaEntine AgathaThreads)

That is assuming that AgathaUtils AgathaEntine AgathaThreads are all 
built in the same project by CMake.


-Bill

___
Powered by www.kitware.com

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

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

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


Re: [CMake] need two compilation to achieve success

2009-06-01 Thread e...@cs.bgu.ac.il

On Mon 01 Jun 15:28 2009 Bill Hoffman wrote:
> e...@cs.bgu.ac.il wrote:
> > On Mon 01 Jun 8:18 2009 Tyler Roscoe wrote:
> 
> > 
> > thanks for the tip, it solved the issue.
> > 
> > 
> 
> I am glad that worked for you but something else is wrong...  How are 
> you linking bin/libs/libAgathaUtils.so' to `bin/AgathaHud' ?  You should 
> have something like:
> 
> target_link_libraries(AgathaHud AgathaUtils)
> 
> That should add the dependency for you.   Do you have that?
> 
> -Bill
> 

I have this:
TARGET_LINK_LIBRARIES(AgathaHud ${LIBRARY_OUTPUT_PATH}/libAgathaUtils.so 
${LIBRARY_OUTPUT_PATH}/libAgathaEngine.so
${LIBRARY_OUTPUT_PATH}/libAgathaThreads.so
cv
PocoXML
PocoFoundation
AR
ARMulti
ARvideo)



___
Powered by www.kitware.com

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

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

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


Re: [CMake] How to guarntee the sequence of build if no target can be used

2009-06-01 Thread Dong Tiger
2009/5/29 Alexander Neundorf 

> On Thursday 28 May 2009, idlecat...@gmail.com wrote:
> > Hi,
> >
> > This situation is:
> >
> > foo.h is generated from foo.x. And foo.h is included by bar.h. And then
> > bar.h is included by a lot of c files. So actually every c files
> including
> > bar.h depends on foo.h.
> > But the file number is so big that I don't want to add dependency for
> each
> > one.
> >
> > How can I specify foo.x is generated before all the c files being
> compiled?
> > It seems add_custom_target works but it will regenerate foo.h every time
> > even the foo.x is not modified.
>
> You should use
> add_custom_command(OUTPUT /foo.h
>   ... )
>
> and then list that generated file as a source file for your target:
>
> add_library(blub /foo.h foo.c bar.c ...)


I know by this way, if foo.h is changed, blub will be rebuilt. But what I
need is foo.h is guaranteed to be up to date before foo.o is built.  I am
not sure if this command is relevant to this. Will cmake try to make sure
all the src files are up to date before compiling any .c files?

>
>
> This should make sure that everything is up to date.
>
> The header-file dependency scanning does in general not work for generated
> files, you need to list the generated file as source file for the targets
> which need it.

Another problem is that I am trying to avoid adding dependencies for these
generated files manually because in my project, there are many generated
head files and quite a few .c files including them. I just want to make sure
the head files are generated before any .c compilation. ADD_CUSTOM_TARGET
can do this but it will regenerate the head files even they are up-to-date.

>
> Alex
>
___
Powered by www.kitware.com

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

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

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

Re: [CMake] "No such file or directory" error when using cmake/swig

2009-06-01 Thread Gerrick Bivins
Thanks for the tip! Searching the docs for the make_directory flag led me to
using:
FILE(MAKE_DIRECTORY directory1 directory2...)

Works perfectly!!!
Thanks again.
Gerrick


On 6/1/09 10:11 AM, "Tyler Roscoe"  wrote:

> cmake -E make_directory

___
Powered by www.kitware.com

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

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

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


Re: [CMake] "No such file or directory" error when using cmake/swig

2009-06-01 Thread Tyler Roscoe
On Mon, Jun 01, 2009 at 09:02:31AM -0500, Gerrick Bivins wrote:
> I thought I could work around this by creating the directory during the
> build but I can't find  any commands to do something similar to "mkdir".

Look at cmake -E make_directory.

You can run that as part of your build process with either
execute_process() or, probably better, with an
add_custom_command()/add_custom_target() combo. See the FAQ for details.

tyler
___
Powered by www.kitware.com

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

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

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


Re: [CMake] Using relative paths with INSTALL

2009-06-01 Thread Brad King

Timothy M. Shead wrote:

Folks:

On a couple of occasions now I've recommended the use of relative paths 
with the OSX bundle installer - this to install files within the bundle 
in "nonstandard" locations.  It would be good to hear from the CMake 
gurus on whether relative paths are supported or not.  For example:


INSTALL(FILES foo DESTINATION ../MacOS)

... note that this only makes sense within the context of an OSX bundle.


The install() command

  http://www.cmake.org/cmake/help/cmake2.6docs.html#command:install

interprets relative DESTINATION paths with respect to the installation
prefix (CMAKE_INSTALL_PREFIX).  No other interpretation is supported.

Are you seeing special behavior for an App Bundle?  Did you set
the prefix to point inside an otherwise manually created bundle?

-Brad
___
Powered by www.kitware.com

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

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

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


[CMake] "No such file or directory" error when using cmake/swig

2009-06-01 Thread Gerrick Bivins
Hello,

I'm trying to use swig & cmake to generate java files for one of my
libraries. The problem I'm having is that I'd like to create a jar from

the output file but I don't know how to create a directory that swig can
write to from Cmake. I've specified:

 

SET(CMAKE_SWIG_OUTDIR
"${PROJECT_BINARY_DIR}/java/src/com/or/vtkormodelreader" ) 

 

In my cmake file but during compile I receive the following error:

 

Unable to open file
E:/work/research/vtkORModelReader/build32/java/src/com/or/vtkormodelread
er\vtkORModelReader.java: No such file or directory

3>Project : error PRJ0019: A tool returned an error code from "Swig
source"

 

If I manually create the directory structure, it works perfectly,
however this isn't the desired behavior.

 

I thought I could work around this by creating the directory during the
build but I can't find  any commands to do something similar to "mkdir".


Am I going about this the wrong way? 

 

Gerrick

___
Powered by www.kitware.com

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

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

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

Re: [CMake] need two compilation to achieve success

2009-06-01 Thread Bill Hoffman

e...@cs.bgu.ac.il wrote:

On Mon 01 Jun 8:18 2009 Tyler Roscoe wrote:




thanks for the tip, it solved the issue.




I am glad that worked for you but something else is wrong...  How are 
you linking bin/libs/libAgathaUtils.so' to `bin/AgathaHud' ?  You should 
have something like:


target_link_libraries(AgathaHud AgathaUtils)

That should add the dependency for you.   Do you have that?

-Bill
___
Powered by www.kitware.com

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

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

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


Re: [CMake] need two compilation to achieve success

2009-06-01 Thread e...@cs.bgu.ac.il

On Mon 01 Jun 8:18 2009 Tyler Roscoe wrote:
> > gmake[2]: *** No rule to make target in/libs/libAgathaUtils.so', needed
> > by in/AgathaHud'. Stop.
> 
> Looks like your dependencies aren't set up correctly. You probably need
> something like:
> 
> add_dependencies (AgathaHud AgathaUtils)
> 
> The first run does eventually get around to creating libAgahtaUtils.so,
> so AgathaHud can find it during the second run.
> 
> These problems are often easier to diagnose/find if you don't do
> parallel builds (no -j flag to make).
> 
> tyler
> 
> On Mon, Jun 01, 2009 at 07:27:09AM +0300, e...@cs.bgu.ac.il wrote:
> > 
> > On Mon 01 Jun 0:01 2009 Tyler Roscoe wrote:
> > > On Sun, May 31, 2009 at 11:56:18PM +0300, e...@cs.bgu.ac.il wrote:
> > > > I've got a strange problem, when I try to compile a clean version of
> > > > my program it fails without any explanation but if I try to compile
> > > > again without running clean I compiles fine...
> > > 
> > > We need way more information to help you. What platform? What compiler?
> > > How exactly does it fail? What do you do to "compile a clean version"?
> > > 
> > > tyler
> > > 
> > 
> > I'm running linux with cmake 2.6.4, gcc 4.3,3. if mean that if I run cmake 
> > clean, then try to compile it when it failes. here:
> > running project clean generates:
> > cd '/home/dagg/workspace/AgathaHud' && VERBOSE="1" LC_MESSAGES="C" 
> > LC_CTYPE="C" /usr/bin/gmake -j3 'clean'
> > /usr/bin/gmake -f CMakeFiles/Makefile2 clean
> > gmake[1]: Entering directory `/home/dagg/workspace/AgathaHud'
> > /usr/bin/gmake -f src/CMakeFiles/AgathaEngine.dir/build.make 
> > src/CMakeFiles/AgathaEngine.dir/clean
> > gmake[2]: Entering directory `/home/dagg/workspace/AgathaHud'
> > cd /home/dagg/workspace/AgathaHud/src && /usr/bin/cmake -P 
> > CMakeFiles/AgathaEngine.dir/cmake_clean.cmake
> > /usr/bin/gmake -f src/CMakeFiles/AgathaHud.dir/build.make 
> > src/CMakeFiles/AgathaHud.dir/clean
> > gmake[2]: Entering directory `/home/dagg/workspace/AgathaHud'
> > cd /home/dagg/workspace/AgathaHud/src && /usr/bin/cmake -P 
> > CMakeFiles/AgathaHud.dir/cmake_clean.cmake
> > gmake[2]: Leaving directory `/home/dagg/workspace/AgathaHud'
> > 
> > /usr/bin/gmake -f src/CMakeFiles/AgathaThreads.dir/build.make 
> > src/CMakeFiles/AgathaThreads.dir/clean
> > gmake[2]: Entering directory `/home/dagg/workspace/AgathaHud'
> > cd /home/dagg/workspace/AgathaHud/src && /usr/bin/cmake -P 
> > CMakeFiles/AgathaThreads.dir/cmake_clean.cmake
> > /usr/bin/gmake -f src/CMakeFiles/AgathaUtils.dir/build.make 
> > src/CMakeFiles/AgathaUtils.dir/clean
> > gmake[2]: Entering directory `/home/dagg/workspace/AgathaHud'
> > cd /home/dagg/workspace/AgathaHud/src && /usr/bin/cmake -P 
> > CMakeFiles/AgathaUtils.dir/cmake_clean.cmake
> > gmake[2]: Leaving directory `/home/dagg/workspace/AgathaHud'
> > 
> > gmake[2]: Leaving directory `/home/dagg/workspace/AgathaHud'
> > 
> > gmake[2]: Leaving directory `/home/dagg/workspace/AgathaHud'
> > 
> > gmake[1]: Leaving directory `/home/dagg/workspace/AgathaHud'
> > 
> > *** Success ***
> > 
> > first compilation attempt:
> > cd '/home/dagg/workspace/AgathaHud' && VERBOSE="1" LC_MESSAGES="C" 
> > LC_CTYPE="C" /usr/bin/gmake -j3 
> > /usr/bin/cmake -H/home/dagg/workspace/AgathaHud 
> > -B/home/dagg/workspace/AgathaHud --check-build-system 
> > CMakeFiles/Makefile.cmake 0
> > /usr/bin/cmake -E cmake_progress_start 
> > /home/dagg/workspace/AgathaHud/CMakeFiles 
> > /home/dagg/workspace/AgathaHud/CMakeFiles/progress.make
> > /usr/bin/gmake -f CMakeFiles/Makefile2 all
> > gmake[1]: Entering directory `/home/dagg/workspace/AgathaHud'
> > /usr/bin/gmake -f src/CMakeFiles/AgathaEngine.dir/build.make 
> > src/CMakeFiles/AgathaEngine.dir/depend
> > gmake[2]: *** No rule to make target `bin/libs/libAgathaUtils.so', needed 
> > by `bin/AgathaHud'. Stop.
> > gmake[2]: *** Waiting for unfinished jobs
> > gmake[2]: Entering directory `/home/dagg/workspace/AgathaHud'
> > cd /home/dagg/workspace/AgathaHud && /usr/bin/cmake -E cmake_depends "Unix 
> > Makefiles" /home/dagg/workspace/AgathaHud 
> > /home/dagg/workspace/AgathaHud/src /home/dagg/workspace/AgathaHud 
> > /home/dagg/workspace/AgathaHud/src 
> > /home/dagg/workspace/AgathaHud/src/CMakeFiles/AgathaEngine.dir/DependInfo.cmake
> >  --color=
> > /usr/bin/gmake -f src/CMakeFiles/AgathaHud.dir/build.make 
> > src/CMakeFiles/AgathaHud.dir/depend
> > gmake[2]: Entering directory `/home/dagg/workspace/AgathaHud'
> > cd /home/dagg/workspace/AgathaHud && /usr/bin/cmake -E cmake_depends "Unix 
> > Makefiles" /home/dagg/workspace/AgathaHud 
> > /home/dagg/workspace/AgathaHud/src /home/dagg/workspace/AgathaHud 
> > /home/dagg/workspace/AgathaHud/src 
> > /home/dagg/workspace/AgathaHud/src/CMakeFiles/AgathaHud.dir/DependInfo.cmake
> >  --color=
> > gmake[2]: Leaving directory `/home/dagg/workspace/AgathaHud'
> > 
> > /usr/bin/gmake -f src/CMakeFiles/AgathaHud.dir/build.make 
> > src/CMakeFiles/AgathaHud.dir/build
> > gmake[2]: Entering directory `/home/dagg/wor