Re: [Liberty-eiffel] Bug #44601

[Mehul Sanghvi]

On Thu, Jun 16, 2016 at 2:58 PM, Raphael Mack <address@hidden> wrote:

Hi,

for the install.sh and tools.sh your patch looks good (even thought I
did not yet try, but maybe we can do it after you have a publicly
accessible git repo.)

One change, that comes to my mind: we meanwhile removed the -fno-gcse
option meanwhile also for Linux systems. There once was a strange bug
which required us to use this option with gcc and we never found out
what the real problem was (and if it was in LibertyEiffel or in gcc ;-)
but as it now works without we don't need it anymore.

Are you referring to bug# 47209 ?  The way I have set things with work/tools.sh and install.sh, it should

compile using -fno-gcse on Linux and Cygwin.  If we do not want this, it is just a matter of removing it

from work/tools.sh. 

 

For the germ your patch is not so easy, because the germ code is
generated by make_germ.sh - which does nothing but a normal
"compile_to_c". So it generates the c-compilation options from the
machine on which it is executed.

Yes I figured that it might not be a good patch, that is why I split it into two separate patches.

 

To make the bootstrap system-independent we might think of changing
install.sh to not use the .make file in germ, but just compile and link
all C files in that directory - with the same options from tools.sh...

Let me think about that.  Should that be part of the work for #44601 or should it be a different task/enhancement ? 

 

What do you think?

I think it makes more sense, and would be a better way to do things compared to the current method.

 

About the other bugs you see I comment inline...

Am Mittwoch, den 15.06.2016, 23:28 -0400 schrieb Mehul Sanghvi:

>      - Add support for *BSD systems

This is a bit generic. Without someone having such a system it is hard
and to be honest not so useful. If you have more concrete ideas, what is
necessary, go on file a task (it's not a bug)

I was going to look at NetBSD / FreeBSD using VMs for them.

 

>      - Add clang support

We should think of a complete restructuring of the platform/compiler
integration into Liberty. I think it would be best to end with a
solution, that doesn't need the Eiffel compiler to know anything about
the OS, the flavor and the c-compiler type at all, but everything is
just coming from the config file and some C/H resources in
sys/runtime...

>      - Rebrand from SmartEiffel to LibertyEiffel
At the beginning the idea was to do a full reimplementation of the
eiffel compiler and using smarteiffel just as transitional bootstrapper,
but it turned out, that this is just too much, so we kept the old
compiler, with the old name.

I personally don't care about the name and I can live with Smart or
Liberty.

I see the same thing with Jenkins/Hudson,  OpenOffice/LibreOffice.  They are rebranded externally (name of executables,

config files, etc.), but internally package and class names still use the older names.   For me its just a consistency thing

as well as a way to say that this is not the same as SmartEiffel.  From what I understand LE has enough changes in it

to distinguish itself on its own.

 

>      - Remove support for older compilers
>      - Remove support for systems that are not being used.

This is already ongoing. Thanks, Hans!

Yes Hans, thanks.

 

>     - Get BDWGC support to work on OSX.  Currently it says that the GC
> is old or missing.  Also occurs on Debian/PPC.

I think we cannot change Liberty to work with an older version, so you
should think of getting a newer libgc version to those systems (should
be possible to install from source if not packaged by the distro)

What I meant was that install.sh is not detecting libgc correctly and so it complains with a generic message that

"either you have an old version, or you don't have it at all".  I would like to improve the detection and handling of

libgc, not make LE work with an older libgc on OSX and Debian/testing on PPC.

 

>  What sort of testing can I do to ensure that what I have built is
> working correctly ? How do I run the tests in the test directory ?

How to run the tests you have already figured out, but to be honest I
think if the bootstrapping works (with a stable compiler) and all the
tools run, you are already in a good state and I wouldn't go for more
but just start using the baby...

Yeah that might be true.  I did see that there were errors due to no libgc handling, so when -bdw_gc was being passed

as an option, things were failing.  If I can get that detection working, it may improve :)  Other than that you're correct, time

to start using the baby now.

 

Cheers,
Rapha

--

Mehul N. Sanghvi
email: address@hidden