Etoile Dependencies Rant

[Martin Dietze]

Hi,

 I've just tried to build Etoile from the SVN again after it had
failed for the n'th time last time (some weeks ago). This time
it was llvm (again) - 2.5 did not suffice, I then pulled the
latest trunk and it failed again - at a different point.

I see two problems with the current approach:

 - if the build depends on an SVN version of third party libs
   (this time it's llvm, but it could as well be any other)
   which are being developed to the point where APIs keep
   changing, it is virtually impossible to assert that you can
   actually build Etoile

 - the INSTALL file was outdated *whenever* I pulled the code
   and tried to setup my system to meet the requirements found
   in there

I appreciate that lots of the stuff in the Etoile SVN is pretty
much cutting edge and does touch third party projects, *but*, if
it goes on like this, people willing to put in some efford will
continuously be discouraged from doing so, and this is bad for
the project.

I'll take another break for a few more weeks...

Cheers,

M'bert

--
----------- / http://herbert.the-little-red-haired-girl.org / -------------
=+=
In C you need #define to get real constants, like "#define FOO (rand())"

_______________________________________________
Etoile-dev mailing list
Etoile-dev@...
https://mail.gna.org/listinfo/etoile-dev

[Quentin Mathé-2]

Hi Martin,

Le 28 juil. 09 à 14:13, Martin Dietze a écrit :

> I've just tried to build Etoile from the SVN again after it had
> failed for the n'th time last time (some weeks ago). This time
> it was llvm (again) - 2.5 did not suffice, I then pulled the
> latest trunk and it failed again - at a different point.

What is the current build error?

> I see two problems with the current approach:
>
> - if the build depends on an SVN version of third party libs
>   (this time it's llvm, but it could as well be any other)
>   which are being developed to the point where APIs keep
>   changing, it is virtually impossible to assert that you can
>   actually build Etoile

I agree that depending that on LLVM svn is a bit troublesome,  
specially when you consider that most people are most interested in  
trying Etoile 'trunk' than 'stable'.
However it is also the price to pay because both LanguageKit and LLVM  
are moving targets evolving quickly.
I might be wrong but we don't depend on any other svn version of third  
party libs. In the past, we also depended on GNUstep svn version, but  
I don't think it is the case currently. If not, let me know so I can  
fix it.

> - the INSTALL file was outdated *whenever* I pulled the code
>   and tried to setup my system to meet the requirements found
>   in there

We tried to regularly scan the commits and update the root README/
INSTALL to list the new dependency which were introduced. However  
that's not optimal since there is always a lag between the time the  
dependency is introduced and the time it got listed.
What I'd like to suggest is to make mandatory that the developer which  
introduces a new dependency must update the INSTALL/README in the same  
commit. This would also apply when a module not included in the build,  
gets included and therefore introduces a new dependency.
Updating INSTALL.FreeBSD and INSTALL.Ubuntu at the same time could  
also be easy to do.

> I appreciate that lots of the stuff in the Etoile SVN is pretty
> much cutting edge and does touch third party projects, *but*, if
> it goes on like this, people willing to put in some efford will
> continuously be discouraged from doing so, and this is bad for
> the project.

ok. We'll try to do better.

Cheers,
Quentin.


_______________________________________________
Etoile-dev mailing list
Etoile-dev@...
https://mail.gna.org/listinfo/etoile-dev

[Martin Dietze]

Hi Quentin,

On Tue, July 28, 2009, Quentin Math� wrote:

> > I've just tried to build Etoile from the SVN again after it had
> > failed for the n'th time last time (some weeks ago). This time
> > it was llvm (again) - 2.5 did not suffice, I then pulled the
> > latest trunk and it failed again - at a different point.
>
> What is the current build error?

With LLVM 2.5 the symbol LLVMContext was undefined. With the
current SVN trunk I get the error as listed at the bottom of
this mail.

>> [... LLVM ...]
> I agree that depending that on LLVM svn is a bit troublesome,  
> specially when you consider that most people are most interested in  
> trying Etoile 'trunk' than 'stable'.
> However it is also the price to pay because both LanguageKit and LLVM  
> are moving targets evolving quickly.

I could think of two variants: (a) fork prereleases from LLVM which
could then be referenced as build dependencies or (b) at least
document which LLVM SVN revision was used when building before
committing code including any changes to the LLVM stuff.

> I might be wrong but we don't depend on any other svn version of third  
> party libs. In the past, we also depended on GNUstep svn version, but  
> I don't think it is the case currently. If not, let me know so I can  
> fix it.

Yes, I was not very precise here, I was actually thinking of
the GNUStep libraries.

Cheers,

M'bert

The LLVM-related error:

Making all for framework LanguageKitCodeGen...
 Compiling file CGObjCGNU.cpp ...
 CGObjCGNU.cpp: In constructor ‘<unnamed>::CGObjCGNU::CGObjCGNU(llvm::Module&, llvm::LLVMContext&, const llvm::Type*, const llvm::Type*)’:
 CGObjCGNU.cpp:228: error: ‘class llvm::LLVMContext’ has no member named ‘getConstantInt’
 CGObjCGNU.cpp: In member function ‘virtual llvm::Constant*<unnamed>::CGObjCGNU::GenerateConstantString(const char*, size_t)’:
 CGObjCGNU.cpp:403: error: ‘class llvm::LLVMContext’ has no member named ‘getConstantInt’
 CGObjCGNU.cpp: In member function ‘llvm::Constant*<unnamed>::CGObjCGNU::GenerateMethodList(const std::string&, const std::string&, const llvm::SmallVectorImpl<std::basic_string<char,
 std::char_traits<char>, std::allocator<char> > >&, const llvm::SmallVectorImpl<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >&, bool)’:
 CGObjCGNU.cpp:717: error: ‘class llvm::LLVMContext’ has no member named ‘getConstantInt’
 CGObjCGNU.cpp: In member function ‘llvm::Constant*<unnamed>::CGObjCGNU::GenerateIvarList(const llvm::SmallVectorImpl<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >&,
 const llvm::SmallVectorImpl<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >&, const llvm::SmallVectorImpl<int>&)’:
 CGObjCGNU.cpp:744: error: ‘class llvm::LLVMContext’ has no member named ‘getConstantInt’
 CGObjCGNU.cpp:754: error: ‘class llvm::LLVMContext’ has no member named ‘getConstantInt’
 CGObjCGNU.cpp: In member function ‘llvm::Constant*<unnamed>::CGObjCGNU::GenerateClassStructure(llvm::Constant*, llvm::Constant*, unsigned int, const char*, llvm::Constant*, llvm::Constant*,
 llvm::Constant*, llvm::Constant*, llvm::Constant*)’:
 CGObjCGNU.cpp:797: error: ‘class llvm::LLVMContext’ has no member named ‘getConstantInt’
 CGObjCGNU.cpp:810: error: ‘class llvm::LLVMContext’ has no member named ‘getConstantInt’
 CGObjCGNU.cpp: In member function ‘llvm::Constant*<unnamed>::CGObjCGNU::GenerateProtocolMethodList(const llvm::SmallVectorImpl<llvm::Constant*>&, const llvm::SmallVectorImpl<llvm::Constant*>&)’:
 CGObjCGNU.cpp:848: error: ‘class llvm::LLVMContext’ has no member named ‘getConstantInt’
 CGObjCGNU.cpp: In member function ‘llvm::Constant*<unnamed>::CGObjCGNU::GenerateProtocolList(const llvm::SmallVectorImpl<std::basic_string<char, std::char_traits<char>, std::allocator<char> >
 >&)’:
 CGObjCGNU.cpp:876: error: ‘class llvm::LLVMContext’ has no member named ‘getConstantInt’
 CGObjCGNU.cpp: In member function ‘virtual void<unnamed>::CGObjCGNU::GenerateProtocol(const char*, const llvm::SmallVectorImpl<std::basic_string<char, std::char_traits<char>, std::allocator<char>
 > >&, const llvm::SmallVectorImpl<llvm::Constant*>&, const llvm::SmallVectorImpl<llvm::Constant*>&, const llvm::SmallVectorImpl<llvm::Constant*>&, const llvm::SmallVectorImpl<llvm::Constant*>&)’:
 CGObjCGNU.cpp:914: error: ‘class llvm::LLVMContext’ has no member named ‘getConstantInt’
 CGObjCGNU.cpp: In member function ‘virtual void<unnamed>::CGObjCGNU::GenerateClass(const char*, const char*, int, const llvm::SmallVectorImpl<std::basic_string<char, std::char_traits<char>,
 std::allocator<char> > >&, const llvm::SmallVectorImpl<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >&, const llvm::SmallVectorImpl<int>&, const
 llvm::SmallVectorImpl<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >&, const llvm::SmallVectorImpl<std::basic_string<char, std::char_traits<char>, std::allocator<char> >
 >&, const llvm::SmallVectorImpl<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >&, const llvm::SmallVectorImpl<std::basic_string<char, std::char_traits<char>,
 std::allocator<char> > >&, const llvm::SmallVectorImpl<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >&)’:
 CGObjCGNU.cpp:990: error: ‘class llvm::LLVMContext’ has no member named ‘getConstantInt’
 CGObjCGNU.cpp:995: error: ‘class llvm::LLVMContext’ has no member named ‘getConstantInt’
 CGObjCGNU.cpp: In member function ‘virtual llvm::Function*<unnamed>::CGObjCGNU::ModuleInitFunction()’:
 CGObjCGNU.cpp:1078: error: ‘class llvm::LLVMContext’ has no member named ‘getConstantInt’
 CGObjCGNU.cpp:1091: error: ‘class llvm::LLVMContext’ has no member named ‘getConstantInt’
 CGObjCGNU.cpp:1106: error: ‘class llvm::LLVMContext’ has no member named ‘getConstantInt’
 CGObjCGNU.cpp:1116: error: ‘class llvm::LLVMContext’ has no member named ‘getConstantInt’
 CGObjCGNU.cpp:1119: error: ‘class llvm::LLVMContext’ has no member named ‘getConstantInt’
 CGObjCGNU.cpp:1137: error: ‘class llvm::LLVMContext’ has no member named ‘getConstantInt’
 CGObjCGNU.cpp:1140: error: ‘class llvm::LLVMContext’ has no member named ‘getConstantInt’
 make[4]: *** [obj/CGObjCGNU.cpp.o] Error 1
 make[3]: *** [LanguageKitCodeGen.all.framework.variables] Error 2
 make[2]: *** [internal-all] Error 2
 make[1]: *** [internal-all] Error 2
 make: *** [internal-all] Error 2

--
----------- / http://herbert.the-little-red-haired-girl.org / -------------
=+=
My opinions may have changed, but not the fact that I am right.

_______________________________________________
Etoile-dev mailing list
Etoile-dev@...
https://mail.gna.org/listinfo/etoile-dev

[David Chisnall]

On 28 Jul 2009, at 17:08, Martin Dietze wrote:

> Hi Quentin,
>
> On Tue, July 28, 2009, Quentin Math� wrote:
>
>>> I've just tried to build Etoile from the SVN again after it had
>>> failed for the n'th time last time (some weeks ago). This time
>>> it was llvm (again) - 2.5 did not suffice, I then pulled the
>>> latest trunk and it failed again - at a different point.
>>
>> What is the current build error?
>
> With LLVM 2.5 the symbol LLVMContext was undefined. With the
> current SVN trunk I get the error as listed at the bottom of
> this mail.

See: https://mail.gna.org/public/etoile-discuss/2009-07/msg00012.html

>>> [... LLVM ...]
>> I agree that depending that on LLVM svn is a bit troublesome,
>> specially when you consider that most people are most interested in
>> trying Etoile 'trunk' than 'stable'.
>> However it is also the price to pay because both LanguageKit and LLVM
>> are moving targets evolving quickly.
>
> I could think of two variants: (a) fork prereleases from LLVM which
> could then be referenced as build dependencies or

The version in -stable builds with LLVM 2.5.

David
_______________________________________________
Etoile-dev mailing list
Etoile-dev@...
https://mail.gna.org/listinfo/etoile-dev

[Martin Dietze]

On Tue, July 28, 2009, David Chisnall wrote:

> > With LLVM 2.5 the symbol LLVMContext was undefined. With the
> > current SVN trunk I get the error as listed at the bottom of
> > this mail.
>
> See: https://mail.gna.org/public/etoile-discuss/2009-07/msg00012.html

Yep, but the trunk as of today does not work either.

Cheers,

M'bert

--
----------- / http://herbert.the-little-red-haired-girl.org / -------------
=+=
"This has been the most frustrating week in my life for a very long time."
 -- Australian soccer legend Paul Wade at Australia vs. Brazil in 1999 --

_______________________________________________
Etoile-dev mailing list
Etoile-dev@...
https://mail.gna.org/listinfo/etoile-dev

[Felix Holmgren]

As I already wrote a few days ago, I also found it a challenge to
compile Etoile. Among other things, I got one error that I could only
resolve by finding a post on the Etoile list (after googling) and
applying a patch by hand. In the end I got stuck on openssl. I will do
another attempt this week, starting from scratch and I will note down
every step I take so that hopefully other people who start from a
clean Ubuntu system will be able to duplicate them (if I succeed). A
couple of questions:

* It seemed to me that the make script in the virtual box image was
much more forgiving than the one in the svn trunk. I didn't go through
the log thoroughly, but thought I saw errors fly by that halted the
compilation when I ran it on a booted Linux system. Is this possible,
and if so, what flags/env variables do I need to set to make the
compiler skip warnings?

* Would you recommend building and installing *all* dependencies
myself rather than using apt-get?

/F

_______________________________________________
Etoile-dev mailing list
Etoile-dev@...
https://mail.gna.org/listinfo/etoile-dev

[Quentin Mathé-2]

Le 29 juil. 09 à 10:20, Felix Holmgren a écrit :

> As I already wrote a few days ago, I also found it a challenge to
> compile Etoile. Among other things, I got one error that I could only
> resolve by finding a post on the Etoile list (after googling) and
> applying a patch by hand.

I'm a bit suprised because the only custom patch that is needed should  
be the LLVM patch on Linux/x86 platform.
And this is clearly mentioned in INSTALL ('Required Software' section)

The other thing is that we don't support LLVM 2.5 anymore unlike  
INSTALL.Ubuntu states. LLVM trunk is currently needed as the main  
INSTALL now states it. I'll fix INSTALL.Ubuntu right now.

> In the end I got stuck on openssl. I will do
> another attempt this week, starting from scratch and I will note down
> every step I take so that hopefully other people who start from a
> clean Ubuntu system will be able to duplicate them (if I succeed). A
> couple of questions:
>
> * It seemed to me that the make script in the virtual box image was
> much more forgiving than the one in the svn trunk. I didn't go through
> the log thoroughly, but thought I saw errors fly by that halted the
> compilation when I ran it on a booted Linux system. Is this possible,
> and if so, what flags/env variables do I need to set to make the
> compiler skip warnings?

You shouldn't have to skip any warning on Ubuntu or FreeBSD. If you  
get a lot of warnings, this just means something is wrong with a  
dependency. The common error is to try to compile Étoilé with GNUstep  
stable versions instead of the unstable versions.
For untested platforms such as NetBSD or Solaris, you could eventually  
remove -Werror for ADDITIONAL_OBJCFLAGS in etoile.make in case you  
want to play a bit with the build process, and try to figure out what  
needs to be fixed.

> * Would you recommend building and installing *all* dependencies
> myself rather than using apt-get?

No, that would be crazy :-)

Cheers,
Quentin.
_______________________________________________
Etoile-dev mailing list
Etoile-dev@...
https://mail.gna.org/listinfo/etoile-dev

[Quentin Mathé-2]

Le 28 juil. 09 à 18:19, Martin Dietze a écrit :

> On Tue, July 28, 2009, David Chisnall wrote:
>
>>> With LLVM 2.5 the symbol LLVMContext was undefined. With the
>>> current SVN trunk I get the error as listed at the bottom of
>>> this mail.
>>
>> See: https://mail.gna.org/public/etoile-discuss/2009-07/msg00012.html
>
> Yep, but the trunk as of today does not work either.

Can you give more details about your platform and which GNUstep, LLVM  
and Étoilé versions/revisions you are currently using for this build?

I did an install from scratch yesterday on Ubuntu 9.04/x86 and  
everything went fine. I used GNUstep trunk (base, gui, back) r28415,  
LLVM trunk r77321 (+ the linux/x86 patch) and Etoile trunk r5039.
I successfully ran Languages/Compiler/test.st.

Cheers,
Quentin.
_______________________________________________
Etoile-dev mailing list
Etoile-dev@...
https://mail.gna.org/listinfo/etoile-dev

[Felix Holmgren]

> Can you give more details about your platform and which GNUstep, LLVM
> and Étoilé versions/revisions you are currently using for this build?
Will do, but I'm booted on OSX (my main work os) now so don't have it
handy. I'm pretty sure that I committed the mistake you mentioned:
wrong GNUstep version (although I saw it mentioned in the readme), so
I'm sorry if I waisted your time. Thanks again for the info, and I'll
hopefully succeed next time (in a day or two).

/F

_______________________________________________
Etoile-dev mailing list
Etoile-dev@...
https://mail.gna.org/listinfo/etoile-dev