/[eiffelstudio]/vendor/gobosoft.com/gobo/current/doc/gexace/Readme.txt
ViewVC logotype

Contents of /vendor/gobosoft.com/gobo/current/doc/gexace/Readme.txt

Parent Directory Parent Directory | Revision Log Revision Log


Revision 90767 - (show annotations)
Tue Jan 22 00:56:30 2013 UTC (6 years, 8 months ago) by manus
File MIME type: text/plain
File size: 28141 byte(s)
Updated svn:eol-style to be native and svn:mime-style to be text/xml

1 Note: Some parts of this file are rather old (especially the
2 beginning of the file) and might be out of date. Information
3 found in the file options.txt is more up-to-date even if it
4 only covers the <option> elements.
5
6 ==========================================================
7
8 *) Specification of XACE
9
10 Status: Draft V4
11
12 There are two XACE documents "system" documents and "cluster" documents. A "system" document specifies the build requirements for a certain application just like a regular ACE file does. A "cluster" document on the other hand describes a library - that is a collection of classes.
13
14 *) "cluster" document
15
16 **) Typical application
17
18 A library ships with an "cluster" document. People using this library no longer need to copy&paste the ACE file from the examples of the library over and over again. Taking care of changes in the cluster structure and other details. In their applications "system" document they simply refer to the libraries "cluster" document.
19
20 **) Syntax
21
22 The root element of the "cluster" document is the "cluster" element.
23 The root element of the "system" document is the "system" element.
24
25 ***) "cluster" element
26 A cluster can be seen as a tree structure containing further clusters, classes, options and externals.
27 ****) Attribute "name" (optional)
28 Assigns a name to a cluster (or library).
29 ****) Attribute "location" (optional)
30 Assigns a directory to a cluster. Any Eiffel source files found in this directory are said to be contained in this cluster. If the attribute is omitted the cluster does not contain classes directly. It still may contain other clusters thus contain classes indirectly. Only clusters found directly in the specified directory are contained in the cluster. Subdirectories and their classes are not.
31 ****) "cluster" element (occurrence: >=0)
32 Nests another clusters one in another. The outer cluster is called the parent cluster and the inner cluster sub-cluster.
33 ****) "mount" element (occurrence: >=0)
34 Specifies a cluster defined in another "cluster" document. The specified cluster and all its sub-clusters are "mounted" into the outer cluster.
35 *****) Attribute "location" (required)
36 Specifies the external "cluster" document
37 *****) Attribute "cluster" (optional)
38 Selects a certain cluster (and its sub-clusters) in the "cluster" document to be included instead of the root cluster of the document. For a syntax description of the "cluster" value see section "Qualified Cluster Names"
39 ****) "description" element (occurrence: >=0)
40 used for plain text description of cluster. this element may change in the future.
41 ****) "options" element
42 "option" elements in nested clusters override their grand siblings.
43 *****) "require" element
44 ******) Attribute "enable" (optional)
45 Maybe "True" or "False". Defaults to "True"
46 *****) "ensure" element
47 ******) Attribute "enable"
48 Maybe "True" or "False". Defaults to "True"
49 *****) "invariant" element
50 ******) Attribute "enable"
51 Maybe "True" or "False". Defaults to "True"
52 *****) "loop" element
53 ******) Attribute "enable"
54 Maybe "True" or "False". Defaults to "True"
55 *****) "check" element
56 ******) Attribute "enable"
57 Maybe "True" or "False". Defaults to "True"
58 *****) "debug" element
59 ******) Attribute "enable"
60 Maybe "True" or "False". Defaults to "True"
61 ******) Attribute "name" (optional)
62 Name of debug assertion to turn on.
63 If ommitted all debug instructions are turned on.
64
65 ***) "system" element
66 A "system" element describes the elements of an application and how to put them together.
67 ****) Attribute "name" (required)
68 Specifies the name of the executable to build.
69 ****) "root" element (occurrences: =1)
70 Specifies the root class name and creation procedure name of the executable.
71 *****) Attribute "class" (required)
72 Specifies the root class name
73 *****) Attribute "creation" (required)
74 Specifies the creation procedure name of the root class
75 ****) "cluster" element (occurrences: >=1)
76 See description above.
77
78 **) Attribute Value expansion
79 "name" and "location" attribute values may contain variables of the form "${VAR_NAME}". If they are defined they will be expanded, otherwise they will be left untouched.
80
81 **) Directory Separators
82 Only slashes ("/") are allowed to separate directories. On platforms where this is not the native separator the path will be converted to the native standards in all output files. Windows drive letter constructs are prohibited.
83
84
85 **) Qualified Cluster Names
86 To address cluster in a nested cluster structure qualified cluster name are used. To address a given cluster prepend its name with the name of its parents separated by a dot (".") followed by the name of the cluster to address. A qualified cluster name may contain variables.
87
88
89 **) Parent Reference
90 If you leave out the "location" attribute of a cluster element, but provide a "name" attribute, the path name of the cluster will be the concatenation of the parents cluster, a slash and the current cluster name.
91
92 **) Variables
93
94 The XACE tool can be given a set of variable->value pairs. Variable names can be used in qualified cluster names to dynamically change the cluster tree at tool invocation time.
95
96 **) Syntax Outlook
97
98 Future versions are likely to make certain attributes (like "creation") optional and assume sensible defaults. It is also likely that new attributes will be introduced to allow finer control over what get's included (like "recursive" for "cluster" and "ref").
99
100 Additionally it will be allowed to nest "external" and "option" elements in "cluster" elements to specify external C dependencies and Eiffel and C compile options.
101
102 **) Good style in writing XACE files
103
104 With packages like GOBO and eXML it is of advantage to include all Eiffel source dirs in the main XACE file. They can be referenced from the example system documents like this:
105 --
106 <mount location="..." cluster="example.tree.formatter"/>
107 --
108 This means that the root cluster of such cluster documents should nest "example" and "library" so one can still address the library only:
109 --
110 <mount location="..." cluster="library/xml"/>
111 --
112 The advantage of this approach comes with the possiblities XACE offer. Imagine a tool that renames a class (say hey-ho to refacturing tools):
113 --
114 gexace --rename-class --from="DS_LIFT" --to="DS_LIST" gobo.xace
115 --
116
117 This command would do everything you would otherwise need to do by hand. It would rename the file "ds_lift.e" to "ds_list.e" and change in all classes "DS_LIFT" to "DS_LIST". If the example clusters are not contained in the library's cluster document, you would need to run the command for each example again.
118
119 The same can be done for feature renaming, which will in practice probably occur more often, but will be a little bit trickier to implement (search&replace more difficult)
120
121
122 *) Discussion of "options" element
123
124 "options" children are a natural choice for the "condition" attribute.
125 Typical use of "condition": release and debug builds.
126
127 **) Possible children of "option"
128
129 ***) "assertions"
130
131 SE supports only a global level ("boost", "require", "check", ...)
132 ISE supports assertion checking to differ in clusters. It supports selective "check"s and IIRC selective checking of preconditions, postconditions, ... is coming down the pipe.
133 VE supports ???
134 What can we do? Find the highest common denominator? Bad idea. If we support a finer grade control, compilers who do not understand these details can be given the highest debug level found in the XACE file.
135
136 We should go for the finest control. Compilers that do not support that level, the highest level will be used. The reason is that it is very likely that in the future all compilers support fine grain control.
137
138 --
139 <require enable="True|False"/>
140 <ensure enable="True|False"/>
141 <invariant enable="True|False"/>
142 <loop enable="True|False"/>
143 <check enable="True|False"/>
144 <debug enable="True|False" name="..."/>
145 --
146
147
148
149 ***) "console_application"
150
151 Only supported by ISE, but does other compilers no harm. We could
152 easily support it.
153
154 TODO: Find other options
155
156 *) "external"
157
158 children of externals are a natural choice for the "condition" attribute.
159 Typical use of "condition": link different libraries on different platforms.
160
161 **) Possible Children of "externals"
162
163 ***) "link"
164
165 Specifies object files or libraries to link with the
166 application. "conditional" attribute allowed
167
168 ***) "include_dir"
169
170 Specifies additional c-header directories
171
172 ***) "export"
173
174 Specifies Eiffel callback features for C.
175 Generates cecil.se file for SE and "visible" clause for ISE. TODO:
176 What about VE and HACT?
177 Example:
178 --
179 <export class="GTK_COMMAND_TYPE">
180 <feature name="enty_from_gtk" alias="eiffel_entry_from_gtk"/>
181 <feature name="gtk_function_entry" alias="eiffel_gtk_function_entry"/>
182 </export>
183 --
184
185
186
187
188 *) Real life examples of XACE
189
190 -- xace.xace the system document used to build the xace tool itself
191 <system name="xace">
192 <root class="XACE" creation="make"/>
193 <cluster>
194 <cluster name="xace" location="${EXML}/src/xace/"/>
195
196 <mount location="${EXML}/library/exml.xace" cluster="exml.interface"/>
197 <mount location="${EXML}/library/exml.xace" cluster="exml.impl.no_expat"/>
198 <mount location="${EXML}/library/exml.xace" cluster="exml.impl.eiffel"/>
199 <mount location="${EXML}/library/exml.xace" cluster="exml.impl.tree_on_event"/>
200 <mount location="${GOBO}/library/gobo.xace" cluster="gobo"/>
201 <mount location="${GOBO}/library/kernel.xace" cluster="kernel.${EIF_COMPILER}"/>
202 </cluster>
203 </system>
204
205 -- kernel.xace cluster document for various kernels
206 <cluster name="kernel">
207 <cluster name="se" location="${SE}/lib_std"/>
208 <cluster name="ise" location="${EIFFEL4}/library/base/kernel">
209 <cluster name="support" location="${EIFFEL4}/library/base/support"/>
210 </cluster>
211 </cluster>
212 -- gobo.xace cluster document for GOBO
213 <cluster name="gobo" location="${GOBO}/library">
214
215 <cluster name="kernel" >
216 <cluster name="spec" >
217 <cluster name="${EIF_COMPILER}" />
218 </cluster>
219 </cluster>
220 <cluster name="structure" />
221 <cluster name="parse" />
222
223 </cluster>
224
225 -- exml.xace cluster document for eXML
226 <cluster name="exml">
227
228 <description>
229 The Eiffel XML Parser Framework
230
231 Please note that you cannot include the root ("exml") cluster
232 and all its sub-clusters, because there are class name clashes
233 due to the factory in use.
234 You have to select "exml.interface" recursively and then
235 from the "exml.impl" cluster the parsers you wish to compile in.
236 You can choose all, but if you decide to leave out a certain parser
237 you must select its counterpart from "exml.no_impl" to keep the
238 factory happy.
239 </description>
240
241 <cluster name="interface" >
242 <cluster name="public" location="${EXML}/library" >
243 <cluster name="factory" />
244 <cluster name="position" />
245 <cluster name="source" />
246 <cluster name="general" />
247 <cluster name="event" />
248 <cluster name="tree" />
249 <cluster name="formater" />
250 <cluster name="xace" >
251 <cluster name="support" />
252 <cluster name="ast" />
253 <cluster name="generator" />
254 <cluster name="parse" />
255 <cluster name="error" />
256 </cluster>
257 </cluster>
258 <cluster name="impl" location="${EXML}/library/impl/interface" >
259 <cluster name="general" />
260 <cluster name="event" />
261 <cluster name="tree" />
262 </cluster>
263 </cluster>
264
265 <cluster name="impl" location="${EXML}/library/impl" >
266 <cluster name="expat" >
267 <cluster name="api" />
268 <cluster name="general" />
269 <cluster name="event" >
270 <externals>
271 <export class="EP_EVENT_PARSER">
272 <feature name="on_element_declaration_procedure" alias="eif_exml_on_element_declaration_proc" />
273 <feature name="on_attribute_declaration_procedure" alias="eif_exml_on_attribute_declaration_proc" />
274 <feature name="on_xml_declaration_procedure" alias="eif_exml_on_xml_declaration_proc" />
275 <feature name="on_entity_declaration_procedure" alias="eif_exml_on_entity_declaration_proc" />
276 <feature name="on_start_tag_procedure" alias="eif_exml_on_start_tag_proc" />
277 <feature name="on_end_tag_procedure" alias="eif_exml_on_end_tag_proc" />
278 <feature name="on_content_procedure" alias="eif_exml_on_content_proc" />
279 <feature name="on_processing_instruction_procedure" alias="eif_exml_on_processing_instruction_proc" />
280 <feature name="on_comment_procedure" alias="eif_exml_on_comment_proc" />
281 <feature name="on_start_cdata_section_procedure" alias="eif_exml_on_start_cdata_section_proc" />
282 <feature name="on_end_cdata_section_procedure" alias="eif_exml_on_end_cdata_section_proc" />
283 <feature name="on_default_procedure" alias="eif_exml_on_default_proc" />
284 <feature name="on_default_expanded_procedure" alias="eif_exml_on_default_expanded_proc" />
285 <feature name="on_start_doctype_procedure" alias="eif_exml_on_start_doctype_proc" />
286 <feature name="on_end_doctype_procedure" alias="eif_exml_on_end_doctype_proc" />
287 <feature name="on_notation_declaration_procedure" alias="eif_exml_on_notation_declaration_proc" />
288 <feature name="on_start_namespace_declaration_procedure" alias="eif_exml_on_start_namespace_declaration_proc" />
289 <feature name="on_end_namespace_declaration_procedure" alias="eif_exml_on_end_namespace_declaration_proc" />
290 <feature name="on_not_standalone_procedure" alias="eif_exml_on_not_standalone_proc" />
291 <feature name="on_external_entity_reference_procedure" alias="eif_exml_on_external_entity_reference_proc" />
292 <feature name="on_unknown_encoding_procedure" alias="eif_exml_on_unknown_encoding_proc" />
293 </export>
294 </externals>
295 </cluster>
296 <cluster name="spec" >
297 <cluster name="${EIF_COMPILER}" />
298 </cluster>
299 <externals>
300 <include_dir location="${EXML}/library/impl/expat/spec/c"/>
301 <link_library location="${EXML}/library/impl/expat/spec/c/libexml-expat-${EIF_COMPILER}.a"/>
302 <link_library location="-lexpat"/>
303 </externals>
304 </cluster>
305 <cluster name="eiffel" >
306 <cluster name="event" />
307 </cluster>
308 <cluster name="tree_on_event" >
309 <cluster name="tree" />
310 </cluster>
311 <cluster name="no_expat" >
312 <cluster name="event" />
313 </cluster>
314 <cluster name="no_eiffel" >
315 <cluster name="event" />
316 </cluster>
317 <cluster name="no_tree_on_event" >
318 <cluster name="tree" />
319 </cluster>
320 </cluster>
321
322 </cluster>
323 --
324
325 *) xace tool todo:
326 **) Feature completeness
327 ***) refactor element "options"
328 ****) How can we select to (not) override options in mounted cluster?
329 ****) How can we override default options for certain classes?
330 ****) How does overriding options in nested clusters work exactly?
331 ***) find out more about VE external and callback mechanisms
332 ***) introduce conditionals to support:
333 ****) multiple builds (release, debug) look into "option"
334 ****) multiple platforms/external dependencies look into "external"
335 ***) rename "xace" tool to "gexace"
336 ***) add hact generation
337 ***) finish ve generation
338 ***) rework cli
339 ****) switch from '--build --se' to '--build="se"'
340 ****) assure standard xace file name "system.xace"
341 ***) (post 1.0) add "recursive" attribute to "cluster" and "mount"
342 ***) (post 1.0) add "abstract" attribute to "cluster"
343 ***) (post 1.0) variable declaration
344 ****) (post 1.0) a variable used in an XACE file must be declared first.
345 ****) (post 1.0) Additional meta data about its use should be given
346 ****) (post 1.0) declare whether it must be an env var, a define or whether it can be both
347 ****) (post 1.0) declare it as a fixed enum (like EIF_COMPILER may be "ise", "se", "ve", "hact")
348 ****) (post 1.0) add command or tool to generate etags file
349
350
351 **) Quality Assurance
352 ***) refactor gobo related classes and try to push them into gobo
353 ***) move xml error classes into eXML
354 ***) add feature documentation
355 ***) add indexing clauses
356 ***) add test-suite
357 ***) think about renaming "inlcude_dir" into "include"
358 ***) refacture code generation
359
360
361 =====================================================
362
363 Subject: Re: [gobo-eiffel-develop] Xace: attribute "prefix" in <cluster>
364 Date: Sat, 27 Apr 2002 00:09:00 +0200
365 From: Eric Bezault <gobosoft@ifrance.com>
366 Reply-To: ericb@gobosoft.com
367 Organization: Gobo
368 To: gobodev <gobo-eiffel-develop@lists.sourceforge.net>
369
370 I have implemented the new Xace syntax in 'gexace' and
371 it is now available in CVS (you would have to run the
372 bootstrap again). The old syntax will still be accepted
373 for some time, although you may get a lot of warning
374 messages and you may get some cluster name clashes in
375 the generated Ace files (because of the new way we
376 handle possible name clashes, with "prefix" in <mount>
377 and "relative" in <cluster>).
378
379 What's new?
380
381 . Files 'cluster.xace' have been renamed as 'library.xace'.
382 . The top element in 'library.xace' is <library> instead
383 of <cluster>.
384 . The element <library> has a compulsory attribute "name".
385 . Elements <cluster> and <mount> (and possibly <option>
386 and <external>) are possible subelements of <library>.
387 . There is no empty <cluster> element in <system> anymore.
388 Elements <option>, <cluster> and <mount> (and possibly
389 <external>) are directly under <system>.
390 . There is a new attribute "relative" in <cluster> as
391 explained in my previous message in this thread:
392
393 > So, now we can have:
394 >
395 > <cluster name="foo" location="bar"/>
396 > -- cluster named "foo" with pathname "bar" which is
397 > -- not relative to the parent cluster's pathname.
398 > -- Examples:
399 > -- <cluster name="list" location="/a/b/c/list"/>
400 > -- <cluster name="list" location="${GOBO}/list"/>
401 > -- <cluster name="root_cluster" location="."/>
402 > -- Note that even though the pathname is not relative
403 > -- to the parent cluster's pathname, this pathname is
404 > -- not necessarily an absolute pathname in the underlying
405 > -- file system.
406 >
407 > <cluster name="foo" location="bar" relative="true"/>
408 > -- cluster named "foo" with pathname "bar" which is
409 > -- relative to the parent cluster's pathname.
410 > -- Examples:
411 > -- <cluster name="my_list" location="my-list" relative="true"/>
412 > -- <cluster name="ds_list" location="list" relative="true"/>
413 > -- <cluster name="list" location="../list" relative="true"/>
414 > -- If I recall correctly, the first example addresses a request
415 > -- that Glenn had a few months ago when one of his directory
416 > -- names was not a valid cluster name. The second example is a
417 > -- better way to solve name clashes than my initial "prefix"
418 > -- suggestion. The third example will produce the following
419 > -- pathname: "parent-full-pathname/../list" ("$/../list" in
420 > -- ISE's syntax).
421 >
422 > Finally, the following construct:
423 >
424 > <cluster name="foo"/>
425 >
426 > is equivalent to:
427 >
428 > <cluster name="foo" location="foo" relative="true"/>
429
430 . There is a new attribute "prefix" in <mount>. All clusters
431 declared in the mounted library will have their names
432 prefixed by the corresponding value.
433 . The clusters of the mounted libraries with the same pathname
434 (i.e. the same value for the attribute "location" in <mount>)
435 will appear only once in the generated Ace file.
436 . If there are two mounted libraries with the same pathname
437 but different prefixes, then the clash can be resolved in
438 either <library> or <system> by repeating the <mount> element
439 but with the chosen prefix (which will overwrite the others).
440 Note that this is slightly different from my initial suggestion
441 where I only mentioned <system>. The advantage of allowing
442 clash resolution in <library> as well is that it allows to
443 solve these clashes once and for all in a file 'library.xace'
444 and mount this file in the 'system.xace' files instead of
445 having to repeat again and again this name clash resolution
446 in each and every 'system.xace'. See for example:
447
448 $GOBO/library/library.xace
449
450 which contains the prefix declarations and:
451
452 $GOBO/library/src/gexace/system.xace
453
454 where there is no need to declare these prefixes individually
455 again.
456 If there is still a prefix name clash, then 'gexace' emits
457 an error message.
458 . In the generated Ace file, the cluster names are those declared
459 in the Xace files with the possible prefixes specified in <mount>.
460 There is no cluster name concatenation anymore behind the scene
461 in 'gexace'.
462 . The command-line option --cluster in 'gexace' has been renamed
463 as --library and the corresponding default input filename is
464 'library.xace' instead of 'cluster.xace'.
465
466 I think that I will nevertheless add the attribute "prefix"
467 in <cluster>, but in a recursive meaning contrary to my
468 initial proposal. The reason why I think that we need "prefix"
469 despite the availability of "relative" in <cluster> comes from
470 this observation (in file $GOBO/library/xml/library.xace):
471
472 ------------
473 <cluster name="impl_interface" location="interface" relative="true" abstract="true">
474 <cluster name="impl_interface_general" location="general" relative="true"/>
475 <cluster name="impl_interface_event" location="event" relative="true"/>
476 <cluster name="impl_interface_tree" location="tree" relative="true"/>
477 </cluster>
478 <cluster name="impl_expat" location="expat" relative="true" abstract="true" if="${GOBO_XML_EXPAT}">
479 <cluster name="impl_expat_api" location="api" relative="true"/>
480 <cluster name="impl_expat_general" location="general" relative="true"/>
481 <cluster name="impl_expat_event" location="event" relative="true"/>
482 </cluster>
483 ------------
484
485 There are similar things in $GOBO/library/tools/library.xace.
486 Wouldn't it look nicer to have:
487
488 ------------
489 <cluster name="interface" prefix="impl_interface" abstract="true">
490 <cluster name="general"/>
491 <cluster name="event"/>
492 <cluster name="tree"/>
493 </cluster>
494 <cluster name="expat" prefix="impl_expat" abstract="true" if="${GOBO_XML_EXPAT}">
495 <cluster name="api"/>
496 <cluster name="general"/>
497 <cluster name="event"/>
498 </cluster>
499 ------------
500
501 and have the prefix applied recursively to the subclusters?
502
503 --
504 Eric Bezault
505 mailto:ericb@gobosoft.com
506 http://www.gobosoft.com
507
508 =====================================================
509
510 Subject: Re: [gobo-eiffel-develop] Xace: attribute "prefix" in <cluster>
511 Date: Mon, 29 Apr 2002 22:08:48 +0200
512 From: Eric Bezault <gobosoft@ifrance.com>
513 Reply-To: ericb@gobosoft.com
514 Organization: Gobo
515 To: gobo-eiffel-develop@lists.sourceforge.net
516
517 Eric Bezault wrote:
518 >
519 > Yes, I have a similar pattern in $GOBO/library/tools/library.xace
520 > with similar cluster names for eiffel/lace/xace parsers and AST
521 > classes. I have now implemented the "prefix" attribute in <cluster>
522 > in my working version (not committed yet to CVS) and the Xace file
523 > is much simplier now. I also added an attribute "prefix" to
524 > <library> to provide a default prefix value to be overwritten
525 > by the "prefix" attribute of <mount>. Here again the Xace files
526 > are simpler because there is no need to repeat a possible prefix
527 > in <mount> in many Xace files when the default value provided
528 > in <library> is OK.
529
530 The attributes "prefix" in <cluster> and <library> are now
531 available in CVS. You need to run the bootstrap to take
532 advantage of it.
533
534 --
535 Eric Bezault
536 mailto:ericb@gobosoft.com
537 http://www.gobosoft.com
538
539 =====================================================
540
541 Subject: Re: [gobo-eiffel-develop] Xace class' <option> and cluster's <external>
542 Date: Thu, 23 May 2002 18:56:05 +0200
543 From: Eric Bezault <gobosoft@ifrance.com>
544 Reply-To: ericb@gobosoft.com
545 Organization: Gobo
546 To: gobodev <gobo-eiffel-develop@lists.sourceforge.net>
547
548
549 Eric Bezault wrote:
550 >
551 > Following the modifications in 'gexace' that I committed to CVS
552 > yesterday, we can now set options to the whole system or to all
553 > classes of a cluster. But in Ace files we can also set options
554 > on a per class basis:
555 >
556 > my_cluster: "pathname"
557 > default
558 > assertion (require)
559 > option
560 > assertion (ensure): FOO, BAR
561 > end
562 >
563 > The 'default' section contains cluster-level options and the 'option'
564 > section contains class-level options. In the same way we have elements
565 > <system> and <cluster> in Xace, I suggest to add the element <class>
566 > to support this new kind of options:
567 >
568 > <cluster name="my_cluster" location="pathname">
569 > <option name="assertion" value="require"/>
570 > <class name="FOO">
571 > <option name="assertion" value="ensure"/>
572 > </class>
573 > <class name="BAR">
574 > <option name="assertion" value="ensure"/>
575 > </class>
576 > </cluster>
577 >
578 > Now, I looked at the different clauses of the <external> section
579 > and considering that we already put many things in <option>, I
580 > don't see why we should have these specific elements anymore.
581 > For example:
582 >
583 > <include_dir location="pathname"/>
584 >
585 > could just be:
586 >
587 > <option name="include" value="pathname"/>
588 >
589 > and:
590 >
591 > <link_library location="pathname"/>
592 >
593 > could be:
594 >
595 > <option name="link" value="pathname"/>
596 >
597 > (Note that "linker" is already used as a system-level options.)
598 >
599 > It is a little bit more complicated for:
600 >
601 > <export class="FOO">
602 > <feature name="eiffel_feature1" alias="external_feature1"/>
603 > <feature name="eiffel_feature2" alias="external_feature2"/>
604 > </export>
605 >
606 > but now that we have <class>, we could also have <feature> to
607 > be more complete, and write:
608 >
609 > <cluster name="my_cluster" location="pathname">
610 > <option name="assertion" value="require"/>
611 > <option name="include" value="/usr/include"/>
612 > <option name="link" value="libfoo.a"/>
613 > <class name="FOO">
614 > <option name="assertion" value="ensure"/>
615 > <feature name="eiffel_feature1">
616 > <option name="export" value="external_feature1"/>
617 > </feature>
618 > <feature name="eiffel_feature2">
619 > <option name="export" value="external_feature2"/>
620 > </feature>
621 > </class>
622 > <class name="BAR">
623 > <option name="assertion" value="ensure"/>
624 > </class>
625 > </cluster>
626 >
627 > According to LACE described in ETL2 page 530-531, the code above
628 > would generate:
629 >
630 > visible
631 > FOO
632 > export
633 > eiffel_feature1, eiffel_feature2
634 > rename
635 > eiffel_feature1 as external_feature1,
636 > eiffel_feature2 as external_feature2
637 > end
638 > end
639 >
640 > whereas the following:
641 >
642 > <class name="FOO">
643 > <feature name="eiffel_feature1">
644 > <option name="export" value="eiffel_feature1"/>
645 > </feature>
646 > </class>
647 >
648 > would generate only:
649 >
650 > visible
651 > FOO
652 > export
653 > eiffel_feature1
654 > end
655 > end
656 >
657 > Likewise, "export" could be an option of <class> and
658 > the following:
659 >
660 > <class name="FOO">
661 > <option name="export" value="FOO"/>
662 > </class>
663 >
664 > would generate:
665 >
666 > visible
667 > FOO
668 > end
669 >
670 > and the following:
671 >
672 > <class name="FOO">
673 > <option name="export" value="BAR"/>
674 > </class>
675 >
676 > would generate:
677 >
678 > visible
679 > FOO as BAR
680 > end
681 >
682 > And we could also combine the option "export" of <class>
683 > and <feature>.
684 >
685 > With this new scheme, we have:
686 >
687 > <system>
688 > <cluster>
689 > <class>
690 > <feature>
691 >
692 > and everything else is an <option> at the different levels.
693 > With "export", not all compilers will support external class
694 > or feature renaming, I'm not even sure the VE can support
695 > "export" at all. So this fits well into the <option> policy.
696
697 All the above is now available in CVS. You'll need to run
698 the bootstrap because of this change of syntax in Xace.
699 As usual the old syntax will still be accepted for some
700 time with some warning messages.
701
702 Contrary to what is said above, the following element:
703
704 <option name="include" value="pathname"/>
705
706 has been replaced by:
707
708 <option name="header" value="pathname"/>
709
710 because "include" has another meaning in LACE (the
711 counterpart of "exclude").
712
713 I have also added more options at different levels. To have
714 details/explanations about the new options, please have a look
715 at $GOBO/doc/gexace/options.txt. This file has been updated
716 with new options, and it also has two new sections: CLASS
717 OPTIONS and FEATURE OPTIONS.
718
719 --
720 Eric Bezault
721 mailto:ericb@gobosoft.com
722 http://www.gobosoft.com
723
724

Properties

Name Value
svn:eol-style native

  ViewVC Help
Powered by ViewVC 1.1.23