[Cmake] Re: Bug #944 for cmake

[Bill Hoffman]

You need to specify generated.h as a full path.
Use the CMAKE_CURRENT_BINARY_DIR to do this.

So, it should look like this:

PROJECT(DEPEND)

SET(SOURCES main.cpp)

ADD_CUSTOM_COMMAND(
    OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/generated.h
    COMMAND touch
    ARGS ${CMAKE_CURRENT_BINARY_DIR}/generated.h
    )
SET(ADDITIONAL_MAKE_CLEAN_FILES ${CMAKE_CURRENT_BINARY_DIR}/generated.h)
SET_SOURCE_FILES_PROPERTIES(main.cpp PROPERTIES OBJECT_DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/generated.h)

ADD_LIBRARY(depend ${SOURCES})

At 01:09 PM 8/19/2004, Clinton Stimpson wrote:

>Ok, I'm still having the problem and I was able to reproduce this on a small scale...
>This is really flaky here.
>
>I've attached my stuff in a tar.gz file with the Makefile in a state where it produces these errors.
>
>I do a "make clean" and "make -j10 main.o" and I get this
>Building Custom command generated.h...
>make: *** No rule to make target `/home/cjstimp/test_progs/cmake/generated.h', needed by `main.o'.  Stop.
>make: *** Waiting for unfinished jobs....
>make: *** Waiting for unfinished jobs....
>
>
>I do a make clean and a "make -j1 main.o" and I get this
>Building Custom command generated.h...
>Building object file main.o...
>
>Any ideas?  I have my 'make' aliased to 'make -j10' because I have a distributed build system.  So just "make" will do the -j10 for me automatically.
>
>Clint
>
>Bill Hoffman wrote:
>
>>I would recommend running any "undocumented features" by the cmake list before
>>using them.   Things may have changed and there may be a new way to do the same
>>thing that is cleaner.   Also, look in the FAQ.   And, I would also recommend
>>the book.  
>>
>>-Bill
>>
>>
>>At 11:46 AM 8/19/2004, Clinton Stimpson wrote:
>> 
>>
>>>I couldn't reproduce it on a smaller scale....  and then  I just changed the order of my cmake commands and it works now.
>>>
>>>I had something like
>>>
>>>ADD_CUSTOM_COMMAND(................)
>>>QT_WRAP_CPP(.....)
>>>QT_WRAP_UI(....)
>>>
>>>and I just changed the order to
>>>
>>>QT_WRAP_CPP(.....)
>>>QT_WRAP_UI(....)
>>>ADD_CUSTOM_COMMAND(................)
>>>
>>>I've used cmake a few times before, but this is my first project where I make my own CMakeLists.txt files.  One of the first thing I noticed that I didn't see in the documentation was that the commands are order dependent.
>>>
>>>Plus, when I want to do some special things, they are in the documentation but I google out there and find someone that did it a certain way using undocumented features.  Is it ok to use those undocumented things?
>>>
>>>Thanks,
>>>Clint
>>>
>>>Bill Hoffman wrote:
>>>
>>>   
>>>
>>>>Why didn't OBJECT_DEPENDS work for you?
>>>>If you know which files include the generated .h file,
>>>>and you use the OBJECT_DEPENDS property as I describe
>>>>in bug 944, it should be OK.   The problem in
>>>>944 was because he did know which files included the generated .h file.
>>>>The fix in that situation was to make all files depend on the .h file,
>>>>which caused too much rebuilding.
>>>>
>>>>-Bill
>>>>
>>>>
>>>>At 10:42 AM 8/19/2004, you wrote:
>>>>
>>>>
>>>>     
>>>>
>>>>>Hi,
>>>>>
>>>>>I was looking around for a solution to a makefile dependency problem I was
>>>>>having.  I have a generated .h file and it cannot be generated for the
>>>>>first time before a .o file that needs it is built.
>>>>>
>>>>>And I was looking at bug #944 and that looks just like what I need.
>>>>>
>>>>>The second time I attempt to make the object file, it is fine.  Then if I
>>>>>touch the .h file, it rebuilds the .o file just fine.  If I touch any of
>>>>>the image files, it rebuilds everything just fine.  It is only that first
>>>>>time does it not generate the header file.
>>>>>
>>>>>I tried the OBJECT_DEPENDS, but that didn't help.
>>>>>
>>>>>I'm using cmake 2.0.0.   When is this going to be fixed?  Or is my problem a
>>>>>different problem?  Is there a work around?
>>>>>
>>>>>I'm trying to convert one of our complicated build systems to use cmake.
>>>>>And so far it has made things much simpler.  But this is one of the show
>>>>>stoppers I'm having.
>>>>>
>>>>>Thanks,
>>>>>Clint    
>>>>>       
>>>>
>>>>     
>>
>>
>> 
>
>