On 7/12/07, Vitor Vasconcelos Araujo Silva <[EMAIL PROTECTED]> wrote:
> The macro use the variable ${PROJECT_NAME} to name the debian control
> file (which will be used to generate the deb package). If cmake complain
> about a rule already outputing the same file, maybe it's because you're
> trying to build packages for many subprojects and two of the subprojects
> use the PROJECT() macro with the same name ?
First of all, thanks for the fast answer.
You're welcome
About the package, indeed I'm trying to build a package of my entire
project. I checked and (as I expected) there are no subprojects with the
same name.
It seems that the macro is called twice while the value of ${PROJECT} didn't
changed (maybe twice in the same file?). If your project is open source, I
can take a look
I this doesn't help you, try giving me more details.
> Also, try to set CMAKE_MODULE_PATH, instead of giving (like me ^^) the
> relative path of the module.
I didn't try to change it yet, but I didn't put your macros in the
default directory for modules. So, if I change the CMAKE_MODULE_PATH to
it, I believe that other MACROS will stop to work. Am I wrong?
No, this variable add path(s) to the standard path where cmake search
modules.
http://www.cmake.org/Wiki/CMake_Useful_Variables
I can say I'm not using a control file, but using the MACRO's
variables.
Ok, but my macro generate a control file name control_${PROJECT_NAME} in
${PROJECT_BINARY_DIR} folder.
Your problem is not to that the file already exist, but that there is two
rule trying to generate the same control file.
(there may be a problem, I should use DEB_TARGET_NAME instead of the project
name, I'll change it tomorrow. I hope it will solve your problem because I'm
soon on vacation for two weeks)
Thanks a lot one more time and I'll try the CMAKE_MODULE_PATH tip.
You're welcome.
Please keep the mailing list in the CC :)
Regards,
Mehdi Rabah
_______________________________________________
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
