Menu
▾
▴
gobo-eiffel-develop
|
From: Eric B. <er...@go...> - 2001-10-13 09:18:23
|
Hi all,
It is now possible to bootstrap the Gobo tools from CVS.
The procedure is quite simple:
. Check out the source code of Gobo.
. Set the environment variable $GOBO.
. Run either:
$GOBO/work/bootstrap/bootstrap.bat <c_compiler> <eiffel_compiler>
or:
$GOBO/work/bootstrap/bootstrap.sh <c_compiler> <eiffel_compiler>
depending on your platform. To find out about the already
supported values for <c_compiler> and <eiffel_compiler>
run the same command with the option '-help'.
For those who have already tried the bootstrap procedure
before, you would have noticed that there is no need to
set $GOBO_OS anymore (this variable still appears in some
geant build files, but it is internally interpreted by
'geant' -- in the same way 'gexace' can internally set the
value for $GOBO_EIFFEL).
There is not need for Makefiles anymore, and hence no cygwin
under Windows. However the directory $GOBO/test has not been
converted to geant build files yet. This will be done soon.
Later on, when you check out new classes or clusters, there
is usually no need to redo a full bootstrap again. Just
run:
geant install
followed by:
geant clean
in the root directory of the library these new classes or clusters
belong to. 'geant' actually finds its instructions in the file
'build.eant'. In order to know the possible command-line arguments
provided by a given build file, type:
geant help
To come back to the bootstrap procedure, since not all C
compilers nor all platforms have been tested, you are welcome
to send patches and/or code to support other C compilers.
For what the Eiffel compiler is concerned, to run properly
the Gobo source code in CVS should be used with one of the
latest SmallEiffel beta releases, with at least ISE Eiffel
5.0 (if you use ISE 4.5 you will have to copy 'es4.exe' to
'ec.exe' to have a chance to make it work), with Visual
Eiffel 3.3 (I think it doesn't work with VE 3.2 under Linux)
and with Halstenbach 4.0 (if you use ISS 3.0 you will have
at least to add DIRECTORY.create_dir to call `create' and
IO_MEDIUM.put_new_line to call `new_line' to have a chance
to make it work).
Finally, note that the version of the Gobo package in CVS
is a development version and not an official release. The
bootstrap procedure is meant to be used by the Gobo developers
and by those who are interested in experiencing with new
functionalities at their own risk. In particular, people
willing to do code/design review, to beta test and/or to
submit patches/suggestions are welcome.
Enjoy!
--
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com
|
|
From: Berend de B. <be...@po...> - 2001-10-13 12:14:57
|
Eric Bezault <er...@go...> writes: > . Check out the source code of Gobo. > . Set the environment variable $GOBO. > . Run either: > > $GOBO/work/bootstrap/bootstrap.bat <c_compiler> <eiffel_compiler> > > or: > > $GOBO/work/bootstrap/bootstrap.sh <c_compiler> <eiffel_compiler> > > depending on your platform. To find out about the already > supported values for <c_compiler> and <eiffel_compiler> > run the same command with the option '-help'. And perhaps you need geant (in your path)?? This is the message I got when executing this command: # work/bootstrap/bootstrap.sh gcc se work/bootstrap/bootstrap.sh: geant: command not found mv: cannot stat `geant1': No such file or directory work/bootstrap/bootstrap.sh: geant: command not found -- Groetjes, Berend. (-: |
|
From: Eric B. <er...@go...> - 2001-10-13 12:22:57
|
Berend de Boer wrote: > > And perhaps you need geant (in your path)?? The bootstrap script should have created it (before actually calling it) and copied it to $GOBO/bin. So this directory should be in your PATH, yes. -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
|
From: Glenn M. <gle...@op...> - 2001-10-14 01:04:41
|
(Sorry I meant to send this reply to the list not just Eric) Hi Eric, The bootstrap process looks really good. It will make keeping up with GOBO development much easier. However, I received the following errors when trying to bootstrap using 'cl' and 'ise'. I'm using ISE Eiffel 5.0.34 and Visual C++ 6.0: ---------------------------------------------------------------------------- --- Error code: VCCH(1) Error: class has deferred feature(s), but is not declared as deferred. What to do: make feature(s) effective, or include `deferred' before `class' in Class_header. Class: LX_LEX_PARSER Deferred feature: token_name From: YY_PARSER_TOKENS ---------------------------------------------------------------------------- --- ---------------------------------------------------------------------------- --- Error code: VCCH(1) Error: class has deferred feature(s), but is not declared as deferred. What to do: make feature(s) effective, or include `deferred' before `class' in Class_header. Class: GEPP_PARSER Deferred feature: token_name From: YY_PARSER_TOKENS ---------------------------------------------------------------------------- --- ---------------------------------------------------------------------------- --- Error code: VCCH(1) Error: class has deferred feature(s), but is not declared as deferred. What to do: make feature(s) effective, or include `deferred' before `class' in Class_header. Class: XF_EVENT_PARSER Deferred feature: token_name From: YY_PARSER_TOKENS ---------------------------------------------------------------------------- --- ---------------------------------------------------------------------------- --- Error code: VCCH(1) Error: class has deferred feature(s), but is not declared as deferred. What to do: make feature(s) effective, or include `deferred' before `class' in Class_header. Class: PR_YACC_PARSER Deferred feature: token_name From: YY_PARSER_TOKENS ---------------------------------------------------------------------------- --- Thanks. Glenn. |
|
From: Glenn M. <gle...@op...> - 2001-10-14 07:56:45
|
Hi Eric, In addition to my last message, everything bootstraps fine using SmallEiffel. I had to get the latest beta version to build. Plenty of C compilation warnings of the form: "integral size mismatch in argument; conversion supplied" using Visual C++ as the C compiler. I get these with C code generated by ISE also. Glenn. > -----Original Message----- > From: gob...@li... > [mailto:gob...@li...]On Behalf Of > Glenn Maughan > Sent: Sunday, 14 October 2001 11:13 AM > To: gob...@li... > Subject: RE: [gobo-eiffel-develop] Bootstrap from CVS > > > (Sorry I meant to send this reply to the list not just Eric) > > Hi Eric, > > The bootstrap process looks really good. It will make keeping up with GOBO > development much easier. > > However, I received the following errors when trying to bootstrap > using 'cl' > and 'ise'. I'm using ISE Eiffel 5.0.34 and Visual C++ 6.0: > > ------------------------------------------------------------------ > ---------- > --- > > Error code: VCCH(1) > Error: class has deferred feature(s), but is not declared as deferred. > What to do: make feature(s) effective, or include `deferred' before > `class' in Class_header. > > Class: LX_LEX_PARSER > Deferred feature: token_name From: YY_PARSER_TOKENS > > ------------------------------------------------------------------ > ---------- > --- > > ------------------------------------------------------------------ > ---------- > --- > > Error code: VCCH(1) > Error: class has deferred feature(s), but is not declared as deferred. > What to do: make feature(s) effective, or include `deferred' before > `class' in Class_header. > > Class: GEPP_PARSER > Deferred feature: token_name From: YY_PARSER_TOKENS > > ------------------------------------------------------------------ > ---------- > --- > > ------------------------------------------------------------------ > ---------- > --- > > Error code: VCCH(1) > Error: class has deferred feature(s), but is not declared as deferred. > What to do: make feature(s) effective, or include `deferred' before > `class' in Class_header. > > Class: XF_EVENT_PARSER > Deferred feature: token_name From: YY_PARSER_TOKENS > > ------------------------------------------------------------------ > ---------- > --- > > ------------------------------------------------------------------ > ---------- > --- > > Error code: VCCH(1) > Error: class has deferred feature(s), but is not declared as deferred. > What to do: make feature(s) effective, or include `deferred' before > `class' in Class_header. > > Class: PR_YACC_PARSER > Deferred feature: token_name From: YY_PARSER_TOKENS > > ------------------------------------------------------------------ > ---------- > --- > > Thanks. > Glenn. > > > _______________________________________________ > gobo-eiffel-develop mailing list > gob...@li... > https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop |
|
From: Eric B. <er...@go...> - 2001-10-14 10:58:40
|
Glenn Maughan wrote: > > In addition to my last message, everything bootstraps fine using > SmallEiffel. I had to get the latest beta version to build. Yes, it works with SE -0.74b7 as well. > Plenty of C compilation warnings of the form: > > "integral size mismatch in argument; conversion supplied" > > using Visual C++ as the C compiler. Yes, I get these warnings as well. It is definitely a problem with the C code generated by the Eiffel compiler. I reported that to D. Colnet 2 years ago, but with no success apparently. Anyway, they are just warnings, the generated executable is OK. > I get these with C code generated by ISE also. Yes, with 5.0 new warnings appeared with the C code generated by ISE. But for these C compilation warnings (both from SE and ISE), I think that it is an Eiffel compiler issue with the C code they generate. There is nothing we can do from the Gobo Eiffel code side. BTW, did you find out whether there was another 'geyacc.exe' in your path which was called during the bootstrap and was causing the VCCH errors? With SmallEiffel you probably don't get these errors because ... the compiler doesn't check them. -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
|
From: Eric B. <er...@go...> - 2001-10-14 10:49:07
|
Glenn Maughan wrote: > > However, I received the following errors when trying to bootstrap using 'cl' > and 'ise'. I'm using ISE Eiffel 5.0.34 and Visual C++ 6.0: Did the bootstrap procedure correctly generate a 'geyacc.exe' in $GOBO/bin? If so it looks like an old version of 'geyacc.exe' (probably the one from the Gobo 2.0 delivery) is still in your path before the one in $GOBO/bin. -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
|
From: Glenn M. <gle...@op...> - 2001-10-15 10:48:24
|
> Did the bootstrap procedure correctly generate a 'geyacc.exe' > in $GOBO/bin? If so it looks like an old version of 'geyacc.exe' > (probably the one from the Gobo 2.0 delivery) is still in your > path before the one in $GOBO/bin. Eric, No other version of geyacc.exe was in the path. Glenn. |
|
From: Glenn M. <gle...@op...> - 2001-10-15 12:18:11
|
The following routine from class XP_API refers to an undefined 'str'. I assume it is supposed to be 'base'. It compiles clean after this change. ----------------------------- exml_XML_SetBase_string (parser_handle: POINTER; base: STRING): BOOLEAN is -- Sets the base to be used for resolving relative URIs in -- system identifiers in declarations. Resolving relative -- identifiers is left to the application: this value will be -- passed through as the base argument to the -- XM_ExternalEntityRefHandler, XML_NotationDeclHandler and -- XM_UnparsedEntityDeclHandler. The base argument will be -- copied. -- Returns zero if out of memory, non-zero otherwise. require parser_handle_not_null: parser_handle /= default_pointer base_not_void: base /= Void local c_str: ANY do c_str := str.to_c Result := ext_exml_XML_SetBase (parser_handle, $c_str) end ----------------------------- Glenn. |
|
From: Eric B. <er...@go...> - 2001-10-15 15:21:52
|
Glenn Maughan wrote: > > The following routine from class XP_API refers to an undefined 'str'. I > assume it is supposed to be 'base'. Yes, you're right. I just checked it with the old eXML code. I will fix it in the CVS code. -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
|
From: Glenn M. <gle...@op...> - 2001-10-16 11:25:25
|
I'm trying to convert to using the Eiffel XML parser in GOBO but need to use
'parse_from_string' as that is the routine I was using with the expat
implementation. It is currently implemented as:
parse_from_string (data: STRING) is
do
check
False -- TODO
end
end
Anyone willing to implement it for me? Please!
Am I correct in assuming that the Eiffel parser will generate the same
events as the expat parser? Does it handle namespace events correctly?
On the expat side, I found that Makefile.win.msc does not compile correctly
using VC++ 6.0. I think it is because the eiffel.h header is expecting the
symbol 'ise' to be defined but 'ISE' is defined instead. Must be
case-sensitive in nmake.
Also the makefile builds the file 'libexml.lib' rather than the
'libexml-expat-${GOBO_EIFFEL}.a' as defined in the library/xml/cluster.xace
file.
Finally, the <external> element in library/xml/cluster.xace uses braces '{}'
rather than parenthesis '()' to surround environment variables for the
externals. It also defines '-lexpat' as a link library. nmake does not seem
to like either of these.
Perhaps there needs to be a few conditional <external> elements that depend
on the OS for the expat clusters. A bit messy!
Glenn.
|
|
From: Eric B. <er...@go...> - 2001-10-16 22:14:17
|
Glenn Maughan wrote:
>
> I'm trying to convert to using the Eiffel XML parser in GOBO but need to use
> 'parse_from_string' as that is the routine I was using with the expat
> implementation. It is currently implemented as:
>
> parse_from_string (data: STRING) is
> do
> check
> False -- TODO
> end
> end
>
> Anyone willing to implement it for me? Please!
I doesn't seem to be complicated (just 4 or 5 lines of code
to pass a string buffer instead of a file buffer to the parser),
but I won't have time to implement it before this weekend
(I'm on the road for business this week, and although I still
have email access, I don't have my usual development environment).
> Am I correct in assuming that the Eiffel parser will generate the same
> events as the expat parser? Does it handle namespace events correctly?
I don't know, I'm not familiar with this code.
> On the expat side, I found that Makefile.win.msc does not compile correctly
> using VC++ 6.0. I think it is because the eiffel.h header is expecting the
> symbol 'ise' to be defined but 'ISE' is defined instead. Must be
> case-sensitive in nmake.
>
> Also the makefile builds the file 'libexml.lib' rather than the
> 'libexml-expat-${GOBO_EIFFEL}.a' as defined in the library/xml/cluster.xace
> file.
>
> Finally, the <external> element in library/xml/cluster.xace uses braces '{}'
> rather than parenthesis '()' to surround environment variables for the
> externals. It also defines '-lexpat' as a link library. nmake does not seem
> to like either of these.
>
> Perhaps there needs to be a few conditional <external> elements that depend
> on the OS for the expat clusters. A bit messy!
As you have noticed, the expat part of the XML library is
one part of the Gobo CVS code which has not been tried
yet. We will definitely have to do something here, the
first thing of course being to take your remarks and bug
fixes into account.
--
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com
|
|
From: Eric B. <er...@go...> - 2001-10-17 23:03:06
|
Glenn Maughan wrote: > > I'm trying to convert to using the Eiffel XML parser in GOBO but need to use > 'parse_from_string' as that is the routine I was using with the expat > implementation. It is currently implemented as: > > parse_from_string (data: STRING) is > do > check > False -- TODO > end > end > > Anyone willing to implement it for me? Please! I just implemented it and committed to CVS. However no testing has been done at all (apart from checking that it compiles with ISE Eiffel). So it's up to you to try it if you want. -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
|
From: Eric B. <er...@go...> - 2001-10-19 13:47:04
|
Glenn Maughan wrote:
>
> On the expat side, I found that Makefile.win.msc does not compile correctly
> using VC++ 6.0. I think it is because the eiffel.h header is expecting the
> symbol 'ise' to be defined but 'ISE' is defined instead. Must be
> case-sensitive in nmake.
>
> Also the makefile builds the file 'libexml.lib' rather than the
> 'libexml-expat-${GOBO_EIFFEL}.a' as defined in the library/xml/cluster.xace
> file.
>
> Finally, the <external> element in library/xml/cluster.xace uses braces '{}'
> rather than parenthesis '()' to surround environment variables for the
> externals. It also defines '-lexpat' as a link library. nmake does not seem
> to like either of these.
>
> Perhaps there needs to be a few conditional <external> elements that depend
> on the OS for the expat clusters. A bit messy!
I have taken all your remarks above into account I have patched
the files so that they can now be compiled with ISE Eiffel under
Windows NT with MSVC++ 6.0. I didn't look at the code for other
platforms or other compilers though. I tried to compile the new
code in CVS with expat_win32bin_1_95_2.exe downloaded from the
SourceForge Expat project and everything seems to compile OK on
my laptop under Windows NT 4.0 with ISE Eiffel 5.0.34. As usual
(hmmm, shame one me ;-)) I didn't try to execute these modifications,
so I'll let experiement with it.
--
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com
|
|
From: Andreas L. <no...@sb...> - 2001-10-19 19:36:50
|
On Fri, Oct 19, 2001 at 03:45:56PM +0200, Eric Bezault wrote: > Glenn Maughan wrote: > > I have taken all your remarks above into account I have patched > the files so that they can now be compiled with ISE Eiffel under > Windows NT with MSVC++ 6.0. I didn't look at the code for other > platforms or other compilers though. I tried to compile the new > code in CVS with expat_win32bin_1_95_2.exe downloaded from the > SourceForge Expat project and everything seems to compile OK on > my laptop under Windows NT 4.0 with ISE Eiffel 5.0.34. As usual > (hmmm, shame one me ;-)) I didn't try to execute these modifications, > so I'll let experiement with it. I think ideally we should replace the Makefile.* mess in /library/xml/impl/expat/spec/c with only one maintainable geant file. This should already be possible with OS-specific tasks and the exec command. But I have that feeling in my stomach that such a geant file won't be that clean and maintainable either. Maybe we can come up with some reusable geant tasks for c compilation and linkage. Such commands will be usefull for other C dependent parts as well (think eposix). OK, I'll try to do some brainstorming. What do we need to do: *) We need to compile 2 c files, make sure they have certain include dirs set and ideally create a static library from the resulting object files. What are the difficulties to overcome: *) Different OSes *) Different Eiffel compilers *) Different C compilers Some random thought: *) On some OSes the include paths are a non issue (on my debian box the headers should be in a directory that is accessible by the c compiler already). What would be the best abstraction level for geant commands? Or should we go for plain execs? The trivial abstraction level would be to create a a compile and create archive command for each c-compiler (and OS combination?) and then use conditionals in the geant files. Can we do better? Maybe we can use a combination of geant commands and geant inheritance (that feature rules :)? Andreas |
|
From: Berend de B. <be...@po...> - 2001-10-20 06:47:53
|
Andreas Leitner <no...@sb...> writes:
> I think ideally we should replace the Makefile.* mess in
> /library/xml/impl/expat/spec/c with only one maintainable geant
> file. This should already be possible with OS-specific tasks and the
> exec command. But I have that feeling in my stomach that such a
> geant file won't be that clean and maintainable either. Maybe we can
> come up with some reusable geant tasks for c compilation and
> linkage. Such commands will be usefull for other C dependent parts
> as well (think eposix).
For eposix I've written a Makefile generator that works quite well
from the reports I've received. It generates Makefile's for Borland,
Microsoft and lcc. It just needs a simple config file.
I think it would be a good thing to move this into geant. It's
dependent on eposix. This might make bootstrap a bit more difficult,
but we can provide a makelib binary for every architecture if
necessary.
> The trivial abstraction level would be to create a a compile and
> create archive command for each c-compiler (and OS combination?) and
> then use conditionals in the geant files. Can we do better? Maybe we
> can use a combination of geant commands and geant inheritance (that
> feature rules :)?
I suggest we create Makefile as Makefiles include certain system
and compiler specific knowledge. Users can have tweaked there Makefile
configurations for example. If you generate a Makefile you can take
advantage of these things.
Here is the makelib (the name of my program) configuration file that
would be more or less ok:
----------------
GOBO
libexpat
library\xml\impl\expat\spec\c
----------------
not tested, but it's not more difficult than this. The first thing is
the enivronment variable, that should contain the start directory. The
second line is the target makefile. The eiffel compiler and c compiler
are attached to that name so you get something like:
libexpat-ise-msc
The third and next lines contain the C files. As the EXML C files are
written exactly like eposix this works. makelib just finds all .c
files and includes them in the generated Makefile.
--
Groetjes,
Berend. (-:
|
|
From: Eric B. <er...@go...> - 2001-10-20 11:19:08
|
Andreas Leitner wrote: > > I think ideally we should replace the Makefile.* mess in > /library/xml/impl/expat/spec/c with only one maintainable > geant file. I agree. That's why I spoke about "patch" in my previous message: I just wanted to make it work for Glenn in the short term. > The trivial abstraction level would be to create a a compile > and create archive command for each c-compiler (and OS combination?) > and then use conditionals in the geant files. Can we do better? As far as I know we already have a geant task for 'lcc'. So perhaps this could be extended to other supported C compilers. -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
|
From: Glenn M. <gle...@op...> - 2001-10-16 11:39:53
|
Great progress GOBO developers! I'm converting Goanna to use gexace and geant and it will make it much easier to manage. A general question first: Eric, do you want feature requests and bugs to be sent to this list or logged on the SourceForge trackers? I'm all for the SourceForge trackers...it increases the activity stats for the project and makes them easy to track. A couple of requests: 1) Would it be possible for gexace to generate Ace files for ISE that use the nested cluster syntax rather than concatenating the parent and child cluster names? For example, the Xace clusters: <cluster name="parent" location="my/path"> <cluster name="child" location="subpath"/> </cluster> could be generated as: parent: "my/path" child (parent): "$/subpath" (if you are not familiar, the '$' in the 'child' cluster is replaced with 'my/path'). This allows the ISE environment to build a tree structure of clusters that is much easier to navigate and quicker to display. 2) This may be a bug. The following Xace cluster: <cluster name="parent" location="my/path"> <cluster name="my-child"/> </cluster> generates: parent: "my/path" my-child: "my/path/my-child" The cluster name 'my-child' is invalid in ISE. Perhaps it needs to be converted to 'my_child'. |
|
From: Eric B. <er...@go...> - 2001-10-16 22:14:21
|
Glenn Maughan wrote: > > A general question first: Eric, do you want feature requests and bugs to be > sent to this list or logged on the SourceForge trackers? I'm all for the > SourceForge trackers...it increases the activity stats for the project and > makes them easy to track. Personnally, I'm not sure I'll have time to manage the SF trackers and would prefer to use the list. I don't think that activity stats is a goal, and other members of the list may be interested in discussing requests or how to fix bugs. A bug tracker might be valuable for big projects, I'm not sure we can really take the full advantage of it at this stage of development in Gobo. Do you (or somebody else) have any experience with SF bug tracker? > A couple of requests: > > 1) Would it be possible for gexace to generate Ace files for ISE that use > the nested cluster syntax rather than concatenating the parent and child > cluster names? I personnally hate this syntax adopted by ISE, so I never use it in my Ace files. That's why Ace files are currently generated the way they are by 'gexace'. > This allows the ISE environment to build a tree structure of clusters that > is much easier to navigate and quicker to display. That's a good reason. I'll have a look at it, but a priori I don't think it should be too difficult to implement it the way you want. > 2) This may be a bug. The following Xace cluster: > > <cluster name="parent" location="my/path"> > <cluster name="my-child"/> > </cluster> > > generates: > > parent: "my/path" > my-child: "my/path/my-child" > > The cluster name 'my-child' is invalid in ISE. Perhaps it needs to be > converted to 'my_child'. The bug is that: <cluster name="my-child"/> should have been rejected by 'gexace'. The attribute 'name' should be a valid Ace file cluster tag. If the name of a directory is not a valid cluster name, you should write it that way: <cluster name="a_valid_tag" location="full/path/name"/> -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
|
From: Eric B. <er...@go...> - 2001-10-17 23:02:57
|
Andreas Leitner wrote: > So we need some kind of eiffel-identifier checker in gexace. > Eric, I assume something similar is in eiffel-tools already. Not yet: in eiffel-tools the check is done by the lexical analyzer during the parsing. So there was no need to write such eiffel-identifier checker routine. > Using only one implementation for the identifier checker has > the additional advantage that should the definition of eiffel > identifiers ever change (think unicode) we only need to adopt > it at one place. Agreed, such routine should definitely be put in the eiffel-tools library so that it can be shared between various tools needing such functionality. -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
|
From: Eric B. <er...@go...> - 2001-10-15 15:22:13
|
Glenn Maughan wrote: > > No other version of geyacc.exe was in the path. This is strange. Can you send me (to my private email address) the generated class GEPP_TOKENS? It should say: generator: "geyacc version 2.1" in the indexing clause and it should include the routine `token_name'. -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
|
From: Eric B. <er...@go...> - 2001-10-16 22:14:14
|
This is just to let everybody know that Glenn managed to bootstrap using ISE in the end. There is no real reason why it didn't work the first time. -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
|
From: Glenn M. <gle...@op...> - 2001-10-17 11:28:57
|
The following cluster element: <cluster name="goanna" location="."> <cluster name="TESTGEN"/> <cluster name="utility_tests" location="utility"/> <cluster name="log4e_tests" location="log4e"/> </cluster> builds an ISE Ace file with the following cluster definitions: goanna: "." goanna_TESTGEN: "./TESTGEN" goanna_utility_tests: "utility" goanna_log4e_tests: "log4e" I would have expected the 'goanna_utility_tests' and 'goanna_log4e_tests' to have the './' of the parent cluster prepended to the path. In the cluster element above I needed to use different names to the paths because existing clusters already used the names 'utility' and 'log4e'. Is this correct? Thanks. Glenn. |
|
From: Eric B. <er...@go...> - 2001-10-17 23:02:53
|
Glenn Maughan wrote:
>
> The following cluster element:
>
> <cluster name="goanna" location=".">
> <cluster name="TESTGEN"/>
> <cluster name="utility_tests" location="utility"/>
> <cluster name="log4e_tests" location="log4e"/>
> </cluster>
>
> builds an ISE Ace file with the following cluster definitions:
>
> goanna: "."
> goanna_TESTGEN: "./TESTGEN"
> goanna_utility_tests: "utility"
> goanna_log4e_tests: "log4e"
>
> I would have expected the 'goanna_utility_tests' and 'goanna_log4e_tests' to
> have the './' of the parent cluster prepended to the path.
With the way it is implemented now, as soon as you
have the attribute 'location', it is meant to be
a full pathname and not a relative pathname to the
parent directory. That's why you got the above behavior.
So you would have had to write:
<cluster name="goanna" location=".">
<cluster name="TESTGEN"/>
<cluster name="utility_tests" location="./utility"/>
<cluster name="log4e_tests" location="./log4e"/>
</cluster>
to get your expected result.
> In the cluster element above I needed to use different names to the paths
> because existing clusters already used the names 'utility' and 'log4e'.
In the Ace file generated by 'gexace' the cluster tags are
actually the concatenation of the parent full tag and the
cluster name, as you could see above with 'goanna_TESTGEN'
for example. So even if you used 'utility' somewhere else,
there is low risk that there will be a name clash.
Now the question is whether the policy of concatenating
tags adopted by 'gexace' is a good thing or not. Another
policy could have been to use directly the values specified
in the 'name' attribute and append 1, 2, 3 ,... when there
are name clashes:
<cluster name="foo" location="path/name">
<cluster name="bar"/>
<cluster name="toto>
<cluster name="bar"/>
</cluster>
</cluster>
how it works now:
foo: "path/name"
foo_bar: "path/name/bar"
foo_toto: "path/name/toto"
foo_toto_bar: "path/name/toto/bar"
other possible solution (not implemented):
foo: "path/name"
bar: "path/name/bar"
toto: "path/name/toto"
bar1: "path/name/toto/bar"
We'd put "bar1" instead of "bar" to avoid the name clash.
What's your opinion on both solutions?
--
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X