Menu
▾
▴
gobo-eiffel-develop
|
From: Uwe S. <us...@on...> - 2001-10-20 05:34:49
|
Hi GOBO team,
if this is the wrong list, please accept my apologizes and point me to the
right one ...
Please consider the following situation:
Compiler is SE, the following lines are code snippets
local
stream: INPUT_STREAM
file: KL_TEXT_INPUT_FILE
do
!!file.make ("test1.c")
file.open_read
stream := file
stream.read_line
The last line results in a feature applied to Void reference problem,
because it calls 'old_read_line' from KL_TEXT_INPUT_FILE, which calls in
turn 'last_string' which is Void. Wouldn't it be better to redefine
'last_string' in a way that it is not an attribute but a function which
returns an internal attribute (simulating once-per-object)? Other
suggestions?
The problem occured while converting ELJ to make use of GOBO io classes.
Best Regards
Uwe
|
|
From: Eric B. <er...@go...> - 2001-10-20 10:26:59
|
Uwe Sander wrote:
>
> Compiler is SE, the following lines are code snippets
>
> local
> stream: INPUT_STREAM
> file: KL_TEXT_INPUT_FILE
> do
> !!file.make ("test1.c")
> file.open_read
>
> stream := file
KL_TEXT_INPUT_FILE indirectly inherits from INPUT_STREAM
using implementation inheritance (export {NONE} all), therefore
even though no Eiffel compiler forbids the above assignment
it is theoritically invalid. At least that's the way I consider
it when I write Eiffel code.
> stream.read_line
Here you have a CAT-call: the entity `stream' is attached to
an instance of KL_TEXT_INPUT_FILE, and the version of
INPUT_STREAM.read_file is exported to NONE in KL_TEXT_INPUT_FILE.
Either you use the Gobo IO classes, or you use SmallEiffel's,
but don't mix and match them. This is likely not to work.
--
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com
|
|
From: Uwe S. <us...@on...> - 2001-10-20 14:52:08
|
Hi,
> KL_TEXT_INPUT_FILE indirectly inherits from INPUT_STREAM
> using implementation inheritance (export {NONE} all), therefore
> even though no Eiffel compiler forbids the above assignment
> it is theoritically invalid. At least that's the way I consider
> it when I write Eiffel code.
Damn, I have overseen the export clause. Sorry for the stupid question.
Regards
Uwe
|
|
From: Eric B. <er...@go...> - 2001-10-20 15:18:18
|
Uwe Sander wrote:
>
> Damn, I have overseen the export clause.
I think that it is more a problem with Eiffel compilers not
reporting CAT-calls (or with the Eiffel language not providing
an explicit implementation inheritance technique) than a problem
with you as a programmer overseeing the export clause (which is
a trick anyway). With expanded inheritance as sketched out in
ETL3 draft, polymorphism with implementation inheritance would
be forbidden (and detected) by the compiler, and therefore we
would have a compilation error with that line:
stream := file
This would make things much clearer that using the convention
whereby "export {NONE} all" means implementation inheritance.
--
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com
|
|
From: Andreas L. <no...@sb...> - 2001-10-20 18:41:13
|
Hi,
I have produced a proof of concept geant file for libexml yesterday. You can find it under library/xml/impl/expat/spec/c/buiild.ant
There were several difficulties to overcome:
*) I need to compile for a special Eiffel compiler / C compiler combination. The geant compile_ise_cl approach seems a bit to less powerfull as we would need so many rules (n*m). For now I offer only a rule per c compiler (which can also be set implicitly via GOBO_CC) and take the eiffel compiler from GOBO_EIFFEL. (which a default to gcc, se)
*) The latest ISE Eiffel beta for linux uses ${ISE_EIFFEL}/studio/spec/${PLATFORM}/include, on windows there is ${ISE_EIFFEL}/bench/spec/${PLATFORM}/include. We need some way to check for the existance of a dir and set a variable depending on the result. Maybe we should come up with some autoconf stuff to overcome all our default-value problems ?
*) The expat backend seems to segfault with ISE on windows and linux, gotta look at it in detail. But the current geant file has been tested to (at least) compile on linux/gcc/se|ise and windows/cl/ise, where linux/gcc/se actually works at runtime too (;
As for Berends makelib. That looks promising as well. With a geant only file we currently have no partial compilation for example. Are there features to:
*) Define MACRONS for the C files, depending on the eiffel compiler
*) Define extra include paths
*) Define extra include paths, depending eiffel compiler
regards,
Andreas
PS: As for the bridge pattern. I totally forgot the advantage of it (thanks Berend for the detailed pro/cons mail) You cannot do what the tree_on_event parser does: Inherit from the event parser and the at runtime plug in any event based parser you want. So we'll stick with the bridge pattern.
|
|
From: Berend de B. <be...@po...> - 2001-10-20 20:32:30
|
Andreas Leitner <no...@sb...> writes: > As for Berends makelib. That looks promising as well. With a geant only file we currently have no partial compilation for example. Are there features to: > *) Define MACRONS for the C files, depending on the eiffel compiler Use, things like ISE or VE are defined and passed to the C compiler. > *) Define extra include paths Not yet. > *) Define extra include paths, depending eiffel compiler Example? With #ifdefs (C code is bad anyway, so make it more bad isn't a problem :-)) ) you can solve this good enough I think. -- Groetjes, Berend. (-: |
|
From: Glenn M. <gle...@op...> - 2001-10-21 08:01:44
|
Andreas, > *) The expat backend seems to segfault with ISE on windows and > linux, gotta look at it in detail. But the current geant file has > been tested to (at least) compile on linux/gcc/se|ise and > windows/cl/ise, where linux/gcc/se actually works at runtime too (; Make sure the dll built for expat on Windows is in your path. This caused seg faults when I was first using it. I have it running with ISE and Windows. Glenn. |
|
From: Andreas L. <no...@sb...> - 2001-10-21 20:04:35
|
On Sun, Oct 21, 2001 at 06:06:18PM +1000, Glenn Maughan wrote:
> Andreas,
>
> > *) The expat backend seems to segfault with ISE on windows and
> > linux, gotta look at it in detail. But the current geant file has
> > been tested to (at least) compile on linux/gcc/se|ise and
> > windows/cl/ise, where linux/gcc/se actually works at runtime too (;
Problem fixed. The see code was still looking for EP_EVENT_PARSER, whereas it has been renamed to XP_EVENT_PARSER. I have also now added code that checks if the class we resolve is actually in the system. An exception is raised otherwise. This code is protected via an #ifdef and can be enabled by setting ${GOBO_C_DEBUG} before executing geant compile in library/xml/impl/expat/spec/c.
I have tested in on linux. Can somebody confirm that this now works on windows too?
Andreas
|
|
From: Eric B. <er...@go...> - 2001-10-21 22:25:59
|
Andreas Leitner wrote:
>
> Problem fixed. The see code was still looking for EP_EVENT_PARSER,
> whereas it has been renamed to XP_EVENT_PARSER. I have also now
> added code that checks if the class we resolve is actually in the
> system. An exception is raised otherwise. This code is protected
> via an #ifdef and can be enabled by setting ${GOBO_C_DEBUG} before
> executing geant compile in library/xml/impl/expat/spec/c.
I had a chance to have a look at the C code in
library/xml/impl/expat/spec/c when I tried to
make it work with MSVC++ 6.0 this week, and
personally I don't think that it is a good way
of programming to access the Eiffel routines
from C by name using Cecil. It is no safe (see
the exception raisings that you added), it is
error-prone (see the segfault you got just
because you renamed a class), and it is not
efficient (class names and feature names are
probably searched for in hash tables each time
the corresponding Eiffel routine is to be
called, even if the routine won't change between
two calls.
A much better solution is to pass the function
pointers of the Eiffel routines from the Eiffel
side to the C side in an initialization routine,
and then the C code has these functions pointers
in global variables once and for all, and there
is no need for Cecil to get them by name anymore.
Example:
In Eiffel code:
f is
do
...
end
g is
do
...
end
initialize is
-- Pass function pointers of `f' and
-- `g' to C.
do
c_initialize ($f, $g)
end
feature {NONE} -- External
c_initialize (fp, gp: POINTER) is
-- Pass function pointers of `f' and
-- `g' to C.
external
"C"
end
In C code:
EIF_PROCEDURE eif_f, eif_g;
void c_initialize (EIF_PROCEDURE fp, EIF_PROCEDURE gp)
{
eif_f = fp;
eif_g = gp;
}
And now you can replace the code:
void exml_on_element_declaration (void *eiffel_object,
const XML_Char *name,
XML_Content *model)
{
#ifdef ise
EIF_PROCEDURE ep;
EIF_TYPE_ID tid;
tid = eif_type_id ("XP_EVENT_PARSER");
#ifdef GOBO_DEBUG
if (tid == EIF_NO_TYPE)
eif_panic ("Type XP_EVENT_PARSER not in system.");
#endif
ep = eif_procedure ("f", tid);
if (ep == 0)
{ eif_panic ("f not found."); }
else
{ (ep) (eif_access(eiffel_object), (void*) name, (void*) model); }
#endif
}
by:
void exml_on_element_declaration (void *eiffel_object,
const XML_Char *name,
XML_Content *model)
{
#ifdef ise
(eif_f) (eif_access(eiffel_object), (void*) name, (void*) model);
#endif
}
It's safer, more robust, more efficient.
PS: Note that in `exml_on_element_declaration' there is
a extra line in the actual code in the C file:
(ep) (eif_access(eiffel_object), (void*) name, (void*) model);
which should be removed, otherwise the routine is
called twice.
--
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com
|
|
From: Andreas L. <no...@sb...> - 2001-10-21 23:30:36
|
On Mon, 2001-10-22 at 00:24, Eric Bezault wrote:
> Andreas Leitner wrote:
> >
> > Problem fixed. The see code was still looking for EP_EVENT_PARSER,
> > whereas it has been renamed to XP_EVENT_PARSER. I have also now
> > added code that checks if the class we resolve is actually in the
> > system. An exception is raised otherwise. This code is protected
> > via an #ifdef and can be enabled by setting ${GOBO_C_DEBUG} before
> > executing geant compile in library/xml/impl/expat/spec/c.
>
> I had a chance to have a look at the C code in
> library/xml/impl/expat/spec/c when I tried to
> make it work with MSVC++ 6.0 this week, and
> personally I don't think that it is a good way
> of programming to access the Eiffel routines
> from C by name using Cecil. It is no safe (see
> the exception raisings that you added), it is
> error-prone (see the segfault you got just
> because you renamed a class), and it is not
> efficient (class names and feature names are
> probably searched for in hash tables each time
> the corresponding Eiffel routine is to be
> called, even if the routine won't change between
> two calls.
>
> A much better solution is to pass the function
> pointers of the Eiffel routines from the Eiffel
> side to the C side in an initialization routine,
> and then the C code has these functions pointers
> in global variables once and for all, and there
> is no need for Cecil to get them by name anymore.
This makes sense. IIRC that dynamic stuff came from Berend. Berend was
there any other reason not to use function pointers?
> Example:
>
> In Eiffel code:
>
> f is
> do
> ...
> end
>
> g is
> do
> ...
> end
>
> initialize is
> -- Pass function pointers of `f' and
> -- `g' to C.
> do
> c_initialize ($f, $g)
> end
Ok, we just need to make sure the globals are thread safe.
> feature {NONE} -- External
>
> c_initialize (fp, gp: POINTER) is
> -- Pass function pointers of `f' and
> -- `g' to C.
> external
> "C"
> end
>
> In C code:
>
> EIF_PROCEDURE eif_f, eif_g;
>
> void c_initialize (EIF_PROCEDURE fp, EIF_PROCEDURE gp)
> {
> eif_f = fp;
> eif_g = gp;
> }
using something like c_assume_initialize should make this thread safe
(if there is a thread issue to begin with - not sure):
void c_assure_initialize (EIF_PROCEDURE fp, EIF_PROCEDURE gp)
{
if (eif_f != null)
eif_f = fp;
if (eif_g != null)
eif_g = gp;
}
Btw, do you know if procedures can be moved around in ISE? Maybe this
sounds like a stupid question, but I really don't know. Meaning do we
need to protect the function pointers?
Anyway, if Berend has no reason why the other approach doesn't work,
I'll convert the code.
thanks,
Andreas
|
|
From: Berend de B. <be...@po...> - 2001-10-22 06:49:57
|
Andreas Leitner <no...@sb...> writes: > This makes sense. IIRC that dynamic stuff came from Berend. Berend was > there any other reason not to use function pointers? Not really. Just that I didn't know that the code Eric showed worked. The code I used was the example code on ISEs website. So perhaps that's the way they assume you write your code, or perhaps its the way you must write this code. I really don't know. And secondly I wanted to have the compiler dependent stuff in the C code. Eric, does your example works with VE/SE/HACT? That would be great, because I too suspect that your code is much faster. We have to check this, who knows what happens behind the scenes :-) -- Groetjes, Berend. (-: |
|
From: Eric B. <er...@go...> - 2001-10-22 08:46:26
|
Berend de Boer wrote: > > Not really. Just that I didn't know that the code Eric showed > worked. The code I used was the example code on ISEs website. So > perhaps that's the way they assume you write your code, or perhaps > its the way you must write this code. I really don't know. Or perhaps they don't know the way to write this code properly ;-) > And secondly I wanted to have the compiler dependent stuff in the C > code. > > Eric, does your example works with VE/SE/HACT? That would be great, > because I too suspect that your code is much faster. We have to check > this, who knows what happens behind the scenes :-) That's a good question. As far as I know the Eiffel code of the example in my previous message has a standard Eiffel syntax, so it should compile with all Eiffel compilers. But nothing's better than actually checking that with all Eiffel compilers to be sure. As for the C code, it is likely that it will be different, but #ifdef in C is not a problem. -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
|
From: Eric B. <er...@go...> - 2001-10-22 08:46:29
|
Andreas Leitner wrote: > > Btw, do you know if procedures can be moved around in ISE? Maybe this > sounds like a stupid question, but I really don't know. Meaning do we > need to protect the function pointers? As far as I know function pointers do not change during the execution of the program and are the same in all threads for a given Eiffel feature. -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
|
From: Eric B. <er...@go...> - 2001-10-21 22:05:15
|
Andreas Leitner wrote:
>
> *) I need to compile for a special Eiffel compiler / C compiler
> combination. The geant compile_ise_cl approach seems a bit to
> less powerfull as we would need so many rules (n*m).
A good combination of generic rules in a build file in
$GOBO/misc with a smart use of geant's variables should
make it possible to write these n*m rules once and for
all. For example have look at the file '$GOBO/misc/eiffel.eant'
and the files 'build.eant' in '$GOBO/src/*', or the file
'$GOBO/misc/test.eant' and the file 'build.eant' in
'$GOBO/test/kernel' or those in '$GOBO/example/test/*'.
These are good examples of how code in build files can
be refactored thanks to geant's inheritance mechanism.
> *) The latest ISE Eiffel beta for linux uses
> ${ISE_EIFFEL}/studio/spec/${PLATFORM}/include, on windows
> there is ${ISE_EIFFEL}/bench/spec/${PLATFORM}/include.
> We need some way to check for the existance of a dir and
> set a variable depending on the result. Maybe we should
> come up with some autoconf stuff to overcome all our
> default-value problems ?
First we can hope that in the next beta versions for Windows
the path will also be named '${ISE_EIFFEL}/studio/...', but
in the meantime here again a smart use of geant's local
variables should do the trick:
<target name="toto" depend="init">
<foo bar="${ISE_EIFFEL}/${studio}/spec/${PLATFORM}/include"/>
</target>
<target name="init">
<geant target="init_os"/>
...
</target>
<target name="init_os">
<geant target="init_windows"/>
<geant target="init_unix"/>
</target>
<target name="init_windows" if="${GOBO_OS}=windows">
<set name="studio" value="bench"/>
...
</target>
<target name="init_unix" unless="${GOBO_OS}=windows">
<set name="studio" value="studio"/>
...
</target>
As a reminder, note that $GOBO_OS is automatically set
by 'geant'.
> As for Berends makelib. That looks promising as well. With a
> geant only file we currently have no partial compilation for example.
What do you mean by "partial compilation"?
--
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com
|
|
From: Andreas L. <no...@sb...> - 2001-10-21 22:21:03
|
On Mon, 2001-10-22 at 00:03, Eric Bezault wrote:
> Andreas Leitner wrote:
> >
> > *) I need to compile for a special Eiffel compiler / C compiler
> > combination. The geant compile_ise_cl approach seems a bit to
> > less powerfull as we would need so many rules (n*m).
>
> A good combination of generic rules in a build file in
> $GOBO/misc with a smart use of geant's variables should
> make it possible to write these n*m rules once and for
> all. For example have look at the file '$GOBO/misc/eiffel.eant'
> and the files 'build.eant' in '$GOBO/src/*', or the file
> '$GOBO/misc/test.eant' and the file 'build.eant' in
> '$GOBO/test/kernel' or those in '$GOBO/example/test/*'.
> These are good examples of how code in build files can
> be refactored thanks to geant's inheritance mechanism.
Yes, but this design assumes we do not get another option. For example
the xml examples can be compiled with or without expat. Other such
options will surely come with time. Now do I need for each option touch
misc/eiffel.eant and add rules (which would clutter it up) that only
make sense for some projects. Or I end up adding an endless number of
rules in the example itself.
I could make a special eiffel.eant for xml project that inherits from
misc/eiffel.eant and let my examples inherit from the new eiffel.eant.
But still the coupling between the options is to tight. There must be a
better way.
> > *) The latest ISE Eiffel beta for linux uses
> > ${ISE_EIFFEL}/studio/spec/${PLATFORM}/include, on windows
> > there is ${ISE_EIFFEL}/bench/spec/${PLATFORM}/include.
> > We need some way to check for the existance of a dir and
> > set a variable depending on the result. Maybe we should
> > come up with some autoconf stuff to overcome all our
> > default-value problems ?
>
> First we can hope that in the next beta versions for Windows
> the path will also be named '${ISE_EIFFEL}/studio/...', but
> in the meantime here again a smart use of geant's local
> variables should do the trick:
>
> <target name="toto" depend="init">
> <foo bar="${ISE_EIFFEL}/${studio}/spec/${PLATFORM}/include"/>
> </target>
>
> <target name="init">
> <geant target="init_os"/>
> ...
> </target>
>
> <target name="init_os">
> <geant target="init_windows"/>
> <geant target="init_unix"/>
> </target>
>
> <target name="init_windows" if="${GOBO_OS}=windows">
> <set name="studio" value="bench"/>
> ...
> </target>
>
> <target name="init_unix" unless="${GOBO_OS}=windows">
> <set name="studio" value="studio"/>
> ...
> </target>
That was my first approach, meanwhile I put this clause out again,
because IMO it is a little ugly. So I added a remark to put a symlink
from "studio" to "bench".
> As a reminder, note that $GOBO_OS is automatically set
> by 'geant'.
>
> > As for Berends makelib. That looks promising as well. With a
> > geant only file we currently have no partial compilation for example.
>
> What do you mean by "partial compilation"?
Aehm, sorry, that was a little unclear. What I meant to say was that
makefiles do only tasks they have to do. Based on dependency analysis -
using timestamp checks etc.
Andreas
|
|
From: Eric B. <er...@go...> - 2001-10-21 22:37:40
|
Andreas Leitner wrote: > > Yes, but this design assumes we do not get another option. For example > the xml examples can be compiled with or without expat. Other such > options will surely come with time. Now do I need for each option touch > misc/eiffel.eant and add rules (which would clutter it up) that only > make sense for some projects. No, don't add anything to misc/eiffel.eant, just add a new .eant file in misc (say misc/cc.eant) that inherits from misc/eiffel.eant and adds the various C compilation rules parameterized with geant's local variables (in the same way the 'compile_<compiler>' targets in misc/eiffel.eant are parameterized). > That was my first approach, meanwhile I put this clause out again, > because IMO it is a little ugly. So I added a remark to put a symlink > from "studio" to "bench". It's your point of view, but I find my solution less ugly, and no need to modify the ISE installation (remember that Gobo should ideally work out of the box). > Aehm, sorry, that was a little unclear. What I meant to say was that > makefiles do only tasks they have to do. Based on dependency analysis - > using timestamp checks etc. A similar mechanism will probably be partially implemented in geant. Sven already started to look at how it could be designed. -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
|
From: Andreas L. <no...@sb...> - 2001-10-21 23:20:45
|
|
From: Andreas L. <no...@sb...> - 2001-10-21 23:21:43
|
On Mon, 2001-10-22 at 00:36, Eric Bezault wrote:
> Andreas Leitner wrote:
> >
> > Yes, but this design assumes we do not get another option. For
example
> > the xml examples can be compiled with or without expat. Other such
> > options will surely come with time. Now do I need for each option
touch
> > misc/eiffel.eant and add rules (which would clutter it up) that only
> > make sense for some projects.
>
> No, don't add anything to misc/eiffel.eant, just add a new
> .eant file in misc (say misc/cc.eant) that inherits from
> misc/eiffel.eant and adds the various C compilation rules
> parameterized with geant's local variables (in the same way
> the 'compile_<compiler>' targets in misc/eiffel.eant are
> parameterized).
Sure, but let's stick with the xml example build.eant files. You can
compile the examples with or without the expat backend enabled. You can
decide this on a per example per compile basis. And take into account
that more such options are thinkable. For each new (boolean) option I
have to double the "compile_" tasks. This does not look attractive to
me.
So if we start with:
compile_ise
compile_se
compile_hact
compile_ve
then we want debug builds as well so we double:
compile_ise
compile_se
compile_hact
compile_ve
compile_ise_debug
compile_se_debug
compile_hact_debug
compile_ve_debug
then we want to compile with expat:
compile_ise
compile_se
compile_hact
compile_ve
compile_ise_debug
compile_se_debug
compile_hact_debug
compile_ve_debug
compile_ise_expat
compile_se_expat
compile_hact_expat
compile_ve_expat
compile_ise_debug_expat
compile_se_debug_expat
compile_hact_debug_expat
compile_ve_debug_expat
then we would like to link against the posix libraries:
compile_ise
compile_se
compile_hact
compile_ve
compile_ise_debug
compile_se_debug
compile_hact_debug
compile_ve_debug
compile_ise_expat
compile_se_expat
compile_hact_expat
compile_ve_expat
compile_ise_debug_expat
compile_se_debug_expat
compile_hact_debug_expat
compile_ve_debug_expat
compile_ise_posix
compile_se_posix
compile_hact_posix
compile_ve_posix
compile_ise_debug_posix
compile_se_debug_posix
compile_hact_debug_posix
compile_ve_debug_posix
compile_ise_expat_posix
compile_se_expat_posix
compile_hact_expat_posix
compile_ve_expat_posix
compile_ise_debug_expat_posix
compile_se_debug_expat_posix
compile_hact_debug_expat_posix
compile_ve_debug_expat_posix
Actually I think the autoconf/autobuild people have a better approach
here. They seperate the task of configuring and building a project into
two tasks. In the first task you call:
./configure --with-expat --debug --my-other-option
and then do a simple
make
We could do something similar: Have a configure.eant file that stores
configuration options.
A configure.eant file (that would grows linearly only) could look like
this:
<configure>
<var name="expat" value="true"/>
<var name="debug" value="true"/>
<var name="posix" value="true"/>
</configure>
This also much more reflects the usage. I do not switch from debug
builds to release builds on every compile. Rather I am doing some work
with debug options enabled, then reconfigure, and then I try some stuff
in release mode. Some goes for expat, etc.
Btw, I think the build options in GOBO will increase as we add
components that do not make sense / are not available on every setup. A
low-maintainace solution to add/remove options will help here.
geant would still work without a configure.eant file. It would just
assume the default values.
We could also add some tool that manipulates the configure.eant file
just like ./configure - if we don't want users to launch their editors.
Such a tool could even run in autodectect mode and for example set expat
only if it can find the library (similar to what ./configure does).
> > That was my first approach, meanwhile I put this clause out again,
> > because IMO it is a little ugly. So I added a remark to put a
symlink
> > from "studio" to "bench".
>
> It's your point of view, but I find my solution less ugly,
> and no need to modify the ISE installation (remember that
> Gobo should ideally work out of the box).
Well, but you assume that all linux users have the latest beta. Earlier
versions do have the old path. Again a ./configure pendant could
autodetect such things.
Andreas
|
|
From: Berend de B. <be...@po...> - 2001-10-22 06:52:02
|
Eric Bezault <er...@go...> writes: > A similar mechanism will probably be partially implemented > in geant. Sven already started to look at how it could be > designed. Why reinvent the wheel? Wouldn't it be an idea for geant to generate Makefiles? Or parts of makefiles one can include. I need a makefile anyway. -- Groetjes, Berend. (-: |
|
From: Eric B. <er...@go...> - 2001-10-22 08:46:22
|
Andreas Leitner wrote: > > So if we start with: > > compile_ise > compile_se > compile_hact > compile_ve Note that I use these above for ease of calling. We could have things like that: geant --define="GOBO_EIFFEL=ise" compile instead of: geant compile_ise but I thought that the short-cut was easier to use (even though more cumbersome to write). > then we want debug builds as well so we double: > > compile_ise > compile_se > compile_hact > compile_ve > compile_ise_debug > compile_se_debug > compile_hact_debug > compile_ve_debug > > then we want to compile with expat: > > compile_ise > compile_se > compile_hact > compile_ve > compile_ise_debug > compile_se_debug > compile_hact_debug > compile_ve_debug > compile_ise_expat > compile_se_expat > compile_hact_expat > compile_ve_expat > compile_ise_debug_expat > compile_se_debug_expat > compile_hact_debug_expat > compile_ve_debug_expat > > then we would like to link against the posix libraries: > > compile_ise > compile_se > compile_hact > compile_ve > compile_ise_debug > compile_se_debug > compile_hact_debug > compile_ve_debug > compile_ise_expat > compile_se_expat > compile_hact_expat > compile_ve_expat > compile_ise_debug_expat > compile_se_debug_expat > compile_hact_debug_expat > compile_ve_debug_expat > compile_ise_posix > compile_se_posix > compile_hact_posix > compile_ve_posix > compile_ise_debug_posix > compile_se_debug_posix > compile_hact_debug_posix > compile_ve_debug_posix > compile_ise_expat_posix > compile_se_expat_posix > compile_hact_expat_posix > compile_ve_expat_posix > compile_ise_debug_expat_posix > compile_se_debug_expat_posix > compile_hact_debug_expat_posix > compile_ve_debug_expat_posix > > Actually I think the autoconf/autobuild people have a better approach > here. They seperate the task of configuring and building a project into > two tasks. In the first task you call: > ./configure --with-expat --debug --my-other-option > and then do a simple > make > > We could do something similar: Have a configure.eant file that stores > configuration options. > > A configure.eant file (that would grows linearly only) could look like > this: > <configure> > <var name="expat" value="true"/> > <var name="debug" value="true"/> > <var name="posix" value="true"/> > </configure> What's wrong with: geant --define="expat=true debug=true posix=true" compile ? Once again having many 'compile_*' tasks was just to make the geant command-line easier to type, but if we want to make build files easier to write we can use the above command-line syntax instead. > This also much more reflects the usage. I do not switch from debug > builds to release builds on every compile. I do. I try to run tests every so often to check that the Gobo classes are still consistent, and I try to do that in all compilation modes. > Well, but you assume that all linux users have the latest beta. Earlier > versions do have the old path. It is very hard to support several Eiffel compilers, so as a rule of thumb we should only support one version per compiler. So either we decide to support ISE 4.5 or 5.0. Then it's up to the users to patch whatever needs to be patched in order to make Gobo work if they don't use the supported compiler version. In our case we are still in development phase (i.e. the version in CVS is not an official release of Gobo), so the rule does not need to be as strict, but official Gobo releases should definitely support only publicly available Eiffel compilers. Beta versions of SmallEiffel can be considered publicly available, but not those of ISE. Anyway I hope that ISE 5.1 will be officially released before we have an official version of Gobo, so this discussion is probably already obsolete ;-) -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
|
From: Andreas L. <no...@sb...> - 2001-10-22 09:03:30
|
On Mon, 2001-10-22 at 10:29, Eric Bezault wrote: > Andreas Leitner wrote: > > > > So if we start with: > > > > compile_ise > > compile_se > > compile_hact > > compile_ve > > Note that I use these above for ease of calling. We > could have things like that: > > geant --define="GOBO_EIFFEL=ise" compile > > instead of: > > geant compile_ise > > but I thought that the short-cut was easier to use > (even though more cumbersome to write). Sure, a --define is ok with me. Some kind of autoconf tool could still generate the correct geant call based on a configuration.eant file then. > What's wrong with: > > geant --define="expat=true debug=true posix=true" compile > > ? Once again having many 'compile_*' tasks was just to make > the geant command-line easier to type, but if we want to > make build files easier to write we can use the above > command-line syntax instead. I am cool with --define, I was just afraid that compile_* would be the _only_ way for passing options to geant. > > This also much more reflects the usage. I do not switch from debug > > builds to release builds on every compile. > > I do. I try to run tests every so often to check that > the Gobo classes are still consistent, and I try to do > that in all compilation modes. > > > Well, but you assume that all linux users have the latest beta. Earlier > > versions do have the old path. > > It is very hard to support several Eiffel compilers, so as > a rule of thumb we should only support one version per > compiler. So either we decide to support ISE 4.5 or 5.0. > Then it's up to the users to patch whatever needs to be > patched in order to make Gobo work if they don't use the > supported compiler version. In our case we are still in > development phase (i.e. the version in CVS is not an > official release of Gobo), so the rule does not need to > be as strict, but official Gobo releases should definitely > support only publicly available Eiffel compilers. Beta > versions of SmallEiffel can be considered publicly available, > but not those of ISE. Anyway I hope that ISE 5.1 will be > officially released before we have an official version > of Gobo, so this discussion is probably already obsolete ;-) Yep, that's why I made a symlink on my installation and used the path with bench in the build file. Once Eiffel 5.1 is out, I can rename the file. If that is ok with you, otherwise, I go and change it back to the variable solution. Andreas |
|
From: Eric B. <er...@go...> - 2001-10-22 08:46:45
|
Berend de Boer wrote:
>
> Why reinvent the wheel? Wouldn't it be an idea for geant to generate
> Makefiles? Or parts of makefiles one can include. I need a makefile anyway.
The primary reason to use geant in Gobo was to avoid using
Makefiles because they are not portable, avoid cygwin on
Windows, etc. And our goal is not to reinvent the wheel
('geant' is already reinventing Jakarta Ant anyway) but
to have fun writing a tool in Eiffel which can be used in
the Gobo package in a portable way.
--
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com
|
|
From: Eric B. <er...@go...> - 2001-10-22 09:18:18
|
Andreas Leitner wrote: > > I am cool with --define, I was just afraid that compile_* would be the > _only_ way for passing options to geant. I'm not sure whether Sven already implemented the command-line option --define, but I'm pretty sure that it's on his TODO list somewhere because if I remember correctly there is already support for command-line defined variables in geant source code. > Yep, that's why I made a symlink on my installation and used the path > with bench in the build file. Once Eiffel 5.1 is out, I can rename the > file. If that is ok with you, otherwise, I go and change it back to the > variable solution. No, that's fine. -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
|
From: Berend de B. <be...@po...> - 2001-10-22 09:25:20
|
Eric Bezault <er...@go...> writes: > > Why reinvent the wheel? Wouldn't it be an idea for geant to generate > > Makefiles? Or parts of makefiles one can include. I need a makefile anyway. > > The primary reason to use geant in Gobo was to avoid using > Makefiles because they are not portable, avoid cygwin on > Windows, etc. A makefile generator (aka autoconf) would get around this problem. Now one has to maintain both a makefile and a geant config file. -- Groetjes, Berend. (-: |
|
From: Andreas L. <no...@sb...> - 2001-10-22 09:41:48
|
On Mon, 2001-10-22 at 09:25, Berend de Boer wrote: > Eric Bezault <er...@go...> writes: > > > > Why reinvent the wheel? Wouldn't it be an idea for geant to generate > > > Makefiles? Or parts of makefiles one can include. I need a makefile anyway. > > > > The primary reason to use geant in Gobo was to avoid using > > Makefiles because they are not portable, avoid cygwin on > > Windows, etc. > > A makefile generator (aka autoconf) would get around this problem. Now > one has to maintain both a makefile and a geant config file. Well, but last I time I checked autoconf was not runable on straight windows. And I don't think that will ever change, since it relies on a lot of tools to be installed (m4, ... IIRC). It will (probably) run with cygwin, but we wanted to avoid a dependency on cygwin. Andreas PS: The problem with mails bouncing should be fixed now. I had to disable a debug message in the mail deliver script. Thanks Berend for the hint. |
×
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