[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Liberty-eiffel] Bug #44601

From: Mehul Sanghvi
Subject: Re: [Liberty-eiffel] Bug #44601
Date: Thu, 16 Jun 2016 15:18:48 -0400

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

for the and 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/ and, 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/ 
For the germ your patch is not so easy, because the germ code is
generated by - 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 to not use the .make file in germ, but just compile and link
all C files in that directory - with the same options from

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

>      - 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

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 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.


Mehul N. Sanghvi
email: address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]