[CMake] add_custom_command - help - to specify a rule that can be used to convert all the .pc files to .cxx files

[Michael Hertling]

On 05/14/2010 09:40 AM, Michael Wild wrote:
> 
> On 14. May, 2010, at 9:19 , Michael Hertling wrote:
> 
>> On 05/14/2010 08:05 AM, Michael Wild wrote:
>>>
>>> On 14. May, 2010, at 7:02 , Thangaraj wrote:
>>>
>>>> Hi All,
>>>>
>>>> I am trying to replace the clearmake build system with cmake for one of my
>>>> corporate projects.
>>>> This is a C++ based project and the interaction to database is being done
>>>> using pro*C/C++ for which a meta compiler was provided by oracle.
>>>> We write the database interaction code in a .pc file, which will be compiled
>>>> by pro*C/C++ compiler (an executable named 'proc') to produce the regular
>>>> .cxx files.
>>>> The generated .cxx files can be compiled using the regular cxx compilers.
>>>>
>>>> I have gone through the details of add_custom_command and found that it can
>>>> be used for the process which i have mentioned above.
>>>> But from the documentation, i see that the source file and target file name
>>>> should be explicitly specified.
>>>> What I am looking for is that, there should be a way by which using a single
>>>> 'add_custom_command' i should be able to specify the rule for all my .pc
>>>> files in a folder.
>>>> In other words, i should be able to say my source files as '*.pc' and my
>>>> target file as 'sorcefile.cxx'.
>>>> Also i would like to have this rule in my master CMakeLists.txt, so that it
>>>> will be available in any sub directory.
>>>>
>>>> Please let me know whether this is possible in cmake and if so, point me to
>>>> a simple example of doing it.
>>>> Appreciate your help on this.
>>>>
>>>> Thanks,
>>>> -Thangaraj
>>>
>>>
>>> No, this is not possible. Initially, when I started with CMake, I also thought this to be a huge drawback. But once you get used to it, you realize it isn't all that big, and it helps you from making mistakes or bad things happening.
>>>
>>> I'd recommend wrapping the add_executable and add_library commands in something like this (untested):
>>>
>>> #- Create an executable from pro*C/C++ sources
>>> # Use like add_executable().
>>> function(proc_add_executable)
>>>  _proc_preprocess_sources(pargs ${ARGN})
>>>  add_executable(${pargs})
>>> endfunction()
>>>
>>> #- Create a library from pro*C/pro*C++ sources
>>> # Use like add_library().
>>> function(proc_add_libraryle)
>>>  _proc_preprocess_sources(pargs ${ARGN})
>>>  add_library(${pargs})
>>> endfunction()
>>
>> If you need to mix proc-generated C++ source files with manually written
>> ones in order to generate an executable or a library you should not wrap
>> ADD_EXECUTABLE() and ADD_LIBRARY() in functions like that. Moreover, you
>> probably want to preserve the possibility to specify some options like
>> SHARED, STATIC or EXCLUDE_FROM_ALL. Thus, I would recommend to use the
>> conversion function directly; cf. QT4_WRAP_CPP():
>>
>> set(PCSRCS x.pc y.pc z.pc)
>> _proc_preprocess_sources(CXXSRCS ${PCSRCS}
>> add_executable(exe a.cxx b.cxx c.cxx ${CXXSRCS})
>>
>> Nevertheless, a function like MW's _proc_preprocess_sources()
>> is, IMO, definitely the right approach for the OP's concern.
> 
> Mixing is no problem, since it automagically finds .pc files and leaves the remaining arguments alone. [...]

Oh, yes, this feature escaped me at the first glance, indeed.

> [...] Of course, if your preprocessing needs to be more flexible (i.e. certain files need to have different flags than others etc.), then you're better off with a separate wrapping function which only processes the .pc files. Depends on your needs...

Flexibility is one point, and another is that such a, say, smart
functionality requires to reliably distinguish the files to process
from something else. From my experience, one can typically find more
or less realistic circumstances which make this distinction fail. Here,
e.g., one cannot have an executable whose name ends in ".pc" - certainly
seldom and probably unwise, but not forbidden.

> If you want to you can replace the hard-coded test for .pc by a variable containing a regular expression, such as:
> 
> if(arg MATCHES PROC_SUFFIX_REGEX)
>   ....
> 
> where PROC_SUFFIX_REGEX might be "\\.(pc|proc)$" or whatever suits you...

This relies on the assumption that proc's source files can actually be
recognized by a regular expression, but from a user's point of view, I
would appreciate - if proc allows it - the possibility to pass in files
with arbitrary names, perhaps even without a recognizable extension at
all.

Of course, the above-mentioned points and my preference for a simplified
pc2cxx function which doesn't further inspect its parameters are just my
personal liking, and if it suits the needs a more sophisticated function
is undoubtedly fine, too.

Regards,

Michael