*Hello Mark! * * * *In my current project we have the header files and c++ files in the same directory. In other projects I have seen them in two different directories. * * * * /Linus*
Den onsdagen den 31:e augusti 2011 skrev Mark Fortner: > Hi Linus, > In ArgoPrint I have a TemplateMetaFile object which contains things like a > file naming template. We could use a similar approach for code generation > templates. > > It's been a while since I've written any C++. If you're generating code do > you typically put the headers in one directory and the implementations in > another directory? Perhaps splitting things up into an API and an SPI > directory? > > Mark > > > On Wed, Aug 31, 2011 at 11:03 AM, Linus Tolke Tigris > <[email protected]<javascript:_e({}, 'cvml', '[email protected]');> > > wrote: > >> Great Mark! >> >> For filenames, I am also thinking C++ where each class has a .h file and a >> .cpp file i.e. two separate templates or a single template that generates >> two files. I want to see this to be determined among the set of templates. I >> assume this is easily fixed. >> >> I agree that it is best to put reverse engineering aside. It is great that >> we state this up front. It simplifies things a lot. >> >> /Linus >> >> >> 2011/8/31 Mark Fortner <[email protected] <javascript:_e({}, 'cvml', >> '[email protected]');>> >> >>> >>> Hi Linus, >>> I'll definitely move the results of the discussion into a wiki page. >>> >>> >>>> I miss two things but it might be my lack of knowledge of what is >>>> included in the template engines. >>>> >>>> - In the template it shall be able to express filename or filenames >>>> to be used. >>>> >>>> I don't know if the template itself should know about the filename, but >>> you can definitely pass a file name to the templating engine. There are two >>> use cases here: >>> >>> >>> - *Straight template-based generation*: you have a class, and an >>> output directory, and a template -- the template engine uses this data to >>> determine where what to write and where to write it. Determining the >>> output >>> directory and classname is rather straight-forward: >>> "${outputdir}/${packageName.toPath()}/${className}.${fileExtension}" >>> - *Project-based generation*: you have a domain class, a project >>> directory, and a template -- the correct directory is determined based on >>> the fact that it's a domain class, it's a Grails project (or some other >>> framework), and we know what the project root directory is. Something >>> like >>> >>> "${projectRoot}/grails-app/domain/${packageName.toPath()}/${className}.groovy" >>> >>> >>>> - Re-generation, importing manual changes from previously generated >>>> files or reverse engineering. Shall this be addressed? Do the template >>>> engines mentioned address this? >>>> >>>> In my mental model, language support = reverse engineering + code >>> generation, and for the time being, I'd be satisified if we just had >>> modifiable templates for code generation. I'm not completely dissatisfied >>> with reveng at the moment, there are just a few bits that are need to be >>> updated to properly support some features in the java language. So I'd >>> rather put reveng to the side for the time being and focus on code >>> generation. My personal feeling is that projects that are small and >>> well-defined are more likely to be worked on by volunteers with limited >>> available time and we should probably try to keep this as minimal as >>> possible. >>> >>> Mark >>> >> >> > ------------------------------------------------------ http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2833963 To unsubscribe from this discussion, e-mail: [[email protected]]. To be allowed to post to the list contact the mailing list moderator, email: [[email protected]]
