[DCPM] To quote or not to quote.

[Neil Williams]

On Friday 01 July 2005 10:58 am, Aaron Trevena wrote:
> On 7/1/05, Steve Marvell <steve at devon-it.co.uk> wrote:
> > Neil Williams wrote:
> > > I'm using Perl to parse some XML and generate C source code, including
> > > the Makefile.am, configure.in, autogen.sh, *.c, *.h and ChangeLog.
> >
> > That's disgusting!

Why? Perl is ideally suited to converting between text formats, it's just a 
simple script - all the important work is and can only be done in C. There is 
no way Perl can deal with this data itself, it would require implementing 
most of GnuCash and a lot of Gnome in Perl - now that would be disgusting.

I parse a data object that is expressed in XML. The structure of that 
object is then recreated in C so that anyone receiving such XML can 
create an application to handle the data contained in the XML.

Perl cannot (and must not) deal with the data, perl is only being used 
to create a suitable structure in C, it ignores the actual data and only 
processes the structure.

Take a look at the homepages from the first message.

It's about generating example and test programs on-the-fly from real data 
objects. I could do it in bash using sed but Perl is more portable.

> > > Naturally, I want to keep the code in the templates in sync with the
> > > code in the real project. However, I do NOT want to have to include
> > > placeholders in the REAL project. The places where the template uses
> > > modified strings are not predictable in a manner that would suit a
> > > regexp.
>
> I'm not sure if I get what you are doing fully..

Objects are generic and are plugged into a wider framework once 
compiled. Different objects are needed for different applications and 
data structures. Generating the C code for such objects is tedious and 
repetitive because it's a long stream of get() and set() routines. It's crying 
out for automation. I've already implemented one method using HTML and PHP, 
the new Perl method is to be fully automatic, taking the description of the 
intended object from XML files written out using the C library or 
hand-edited.

The real project is Pilot-QOF and the generated code from that project is 
needed to provide a front-end for QOF-generator. The Perl is used to generate 
the objects and adapt the existing application to use the names used in the 
XML.

The code in the real project is the basis of each generated application. 
The generated application never changes, just the objects and names.

In time, the one application will be adapted to load objects from C libraries 
at runtime.

Each object has it's own .c and .h file - 90% of which is generated 
directly from the XML. When a <string> tag is parsed, a string type 
get() and set() routine are created using the name set in the XML for the name 
of the functions and the parameter itself, the object parameters have a 
string (char*) access method and the struct behind the object itself gets a 
const char* to hold the data. Other data types are boolean, rounded_numeric, 
hexadecimal unique identifiers, single char, integers, longs, lists and 
frames of keys with values. The object files themselves are fine, the only 
long strings used are the GPL header and copyright notice. These don't need 
any templates - nor do they need updating regularly.

The area of most concern for me is the application itself. This is v.closely 
based on pilot-QOF and needs to be as easy to update from that project as 
possible. No markers, no hand-editing, no template placeholders. Yet it is 
90% unchanged between runs, just changes to the names of the objects and the 
header files to include with consequent changes to Makefiles and configure 
scripts.

> You seem to be mucking about with big intepolated strings when you
> should be using a real templating system.

No, I cannot. The strings CANNOT and MUST NOT ever contain any markers, 
Perl, customised comments or placeholders. They are and remain plain C.

That's why I don't want to use quote marks because it requires hand 
editing of the files when copying modified code into the generation project.

The code being copied into the generation project is REAL C code from a 
real project and as that improves, I want to be able to simply copy 
files or snippets into place to update the generated projects with the 
same C changes. The Perl itself won't change. Ideally I'd like to be able to 
do this by simply applying the same patch as I use on the original C files.

This also allows existing generated applications to be patched to the latest 
application code, a quick rebuild and it's done.

> Have you considered using Template Toolkit rather than string/text
> manipulation?

Won't work as the "templates" cannot be marked up. There's no way of Perl 
handling the C directly in any intelligent manner. e.g. how do you tell Perl 
to make valid changes to a Makefile.am or configure.ac? These files *cannot* 
be marked up as templates because of the varying syntax problems and because 
they come from a real project where these markers are unwanted.

> I know that doesn't answer your immediate problem, but if you continue
> along your current lines rather than switching to something like
> Template Toolkit things will only get harder and more unmanagable.

It doesn't need to grow - every object can be handled by the same script 
because of the rules built within the framework. If it works for one it 
will work for all because of how this particular XML output is created.

It's already working - I just want to make it easier to update.

-- 

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.pm.org/pipermail/devoncornwall-pm/attachments/20050701/30ffe10c/attachment.bin