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 [email protected] https://mail.gna.org/listinfo/etoile-dev
