#17 make the skin generation order independant

[Anonymous]

it turns out that the code generated by the cppcms_tmpl_cc tool depends on the order of the .tmpl files it gets.

instead of worring about providing the .tmpl files in the correct order (this is hard to do automaticaly
why not enhance the generated code to be order independant.

the correct way to do this IMHO is to generate header file and cpp file - and include the cpp file in this.

the hpp file will contain 2 parts (again to allow any order): forward declarations for all generated types; And then a complete definition of all the types (virtual function prototypes...)

the cpp file will contain the anonymous namespace currently generated, and the function body for all the functions generated today.

i whould also like to introduce a new template command:
the <% c++ ... %> should provide a way to inject code into the cpp file
while the <% h++ ... %> should provide a way to inject code into the header file (at the detailed section if it is inside a template - or at the forward section if it is ourside a template)

[Anonymous]

I did not found the cppcms_tmpl_cc source code in the svn - or i whould have attempted to generate a patch myself

[Artyom Beilis]

I actually planned to do this for the next (1.2) release but I hadn't get to
it - it is mostly required for plugins support.

It shouldn't be that hard but it requires some significant changes in the cppcms_tmpl_cc. So I had not time to start them.

If you can provide a patch that optionally allows to generate header and
source files it would be great - of course it should be backward compatible
with existing code so it would not break.

Now using anonymous namespace is bad idea and there is no need for it. As C++ code in any case goes to its own namespace.

[Anonymous]

you have an anonymous namespace in the current code generated by cppcms_tmpl_cc

i came to think about it more - and i think that for backward compatibility it might be better to place all the 3 sections in one large cpp file - and then the header file can be made optional very easily

if you can point me to where the cppcms_tmpl_cc code is located (i did not found it in the cppcms svn trunk) i will attempt to make a patch for your review

i run into this problem when i tried to automate my makefile
i generated the skin dependancy list using: find . -name "*.tmpl"
and of course i did not got it in the correct order of dependancy

[Artyom Beilis]

you have an anonymous namespace in the current code generated by cppcms_tmpl_cc

Yes this is for class loader (not the code itself). This is yet another stuff that should be fixed, because today the class loader is generated for entire skin. It probably should go to a separate cpp file.

and i think that for backward compatibility it might be better to place all the 3 sections in one large cpp file

The current code generation method should be kept as is. The code should not generate ".h" file or some dummy headers, but rather the code as is. Think of a case when <% c++ ... %>
includes a code for new classes or some complex part that should go to header.

where the cppcms_tmpl_cc code is located

It is located under ./bin section - it is a python script

---

Also note, before you submitting a patch, note the Copyright policy:

http://cppcms.com/wikipp/en/page/cppcms_1x_coding_standards#Copyrights

[Anonymous]

I will take a look at the code this evening as for copy write - if i manage to get a patch i am happy with - you are free to take ownership on it.

One thing - there is a problem with the <% c++ ... %> syntax

in order to make the compilation order independent there is a need for 3 sections of the file:

the first containing forward declarations for all generated classes - here <% c++ ... %> should not appear at all - although include commands will be nice above this section - so perhaps a new syntax <% #include .... %> (i am not suggesting #... syntax since other things like #ifndef are very problematic)

the second contains the actual class definitions - here <% c++ ... %> commands make sense both for type definitions and other useful things

the third section contains the actual function code for all the functions generated - here <% c++ ... %> commands make sense for making the function do things the template are not able to do with their current syntax

any custom C++ code in the first section can be moved to the second part - so lets skip that option altogether

the problem is with identifying where the C++ code should be in the second or 3rd sections. i think that a good rule of thumb is this:
if the <% c++ ... %> is inside a template - it belongs to the 3rd section - otherwise it belongs to the second

i got home since i started this response and now - and managed to sneak a first look at cppcms_tmpl_cc - i need to refresh my python skill a bit, but the code is readable, and i hope i will have a first patch for your feedback in a few days.

[Lucile]

Hello,
Since this feature request is still open, I attempted to change cppcms_tmpl_cc.
Here is my patch.
It is not a refactoring of cppcms_tmpl_cc: I added a function which open each files, parse classes name and parent classes name, and order the list of files depending on classes (parent then children, etc.) before C++ code generation.