Hello, I noticed Gentoo doesn't have a compiler for the very promising, and much under-appreciated OO language, Eiffel! Doing away with the many flaws of current conventional languages, Eiffel is a Software Engineer's dream. Clean and inobtrusive syntax and a good implementation of multiple inheritence (who said it was impossible?) is just a few of its attractive perks. It strongly supports creating reusable and maintainable code. SmartEiffel is a free implementation of the language, written mostly in Eiffel. It's still beta, so it's still a bit messy in some areas. All it requires is an ANSI C compiler (like gcc).
Created attachment 4518 [details] eBuild
Created attachment 4519 [details] Changelog
Created attachment 4520 [details] smarteiffel-1.0_beta4.ebuild
Created attachment 4521 [details] ChangeLog
Created attachment 4522 [details] 20smarteiffel-1.0_beta4
Created attachment 4523 [details] digest-smarteiffel-1.0_beta4
Created attachment 4524 [details] loadpath.UNIX-1.0_beta4
Attached the appropriate files. Ignore the first 2 files, I made. :) As for the last 3 files, they should go into the "files/" subdirectory.
*** Bug 6365 has been marked as a duplicate of this bug. ***
Hi Steven Thank you for your submission! Unfortunately it has a big problem - it installs eiffel into /opt. As you probably know we are striving to be FHS and LSB compliant. According to FHS /opt is reserved for binary only and few "excepional" packages (e.g. openoffice). smarteiffel is a compiled GPL app, so it apparently does not fall under these criteria. I discussed this issue with other developers and the conclusion was that smarteiffel should belong to /usr. I am going to get back to your submission when I process other new submissions/updates. It may tremendously speed things up if you could take a look inot this issue. Could you please check how this is done in red hat/debian/others? Where rpm's put this app under? (btw, the link to red hat's rpm off the site is now empty). The following link may be of some help: http://cvs.mandrakesoft.com/cgi-bin/cvsweb.cgi/SPECS/SmallEiffel/SmallEiffel-1.23.1.spec?rev=1.5&content-type=text/x-cvsweb-markup One easier way to resolve this situaton may be to install this app under /usr/smarteiffel. However this is also not really FHS compilant. (and it will have to go at least into ${PV} under that dir). I am going to bring this question up on a wider basis. George
Hi Steven. I have spent some more time on this topic and I think I found the solution. Please take a look at how debian handles this package: http://packages.debian.org/unstable/devel/smalleiffel.html Specifically the link to [smalleiffel_1.16.0.74-1.diff.gz] contains diffs made by debian developer that install small/smarteiffel in a sane way. The file debian/rules (after you apply the patch against the corresponding original sources) contains the recipes on how the build and installation is done. Parts of it can be adopted into the ebuild. The end result is that the package gets installed into these dirs: usr/bin - symlinks to eiffel executables usr/lib/smalleiffel/sys usr/share/man/man1 usr/share/doc/smalleiffel - this should be usr/share/doc/${PF} in our case usr/lib/smalleiffel/bin usr/lib/menu - debian specific, should probably be omitted As you see, docs and libs go where they should. Binaries reside with libs, but this seems to be the most sane way to handle this situation. Could you please modify the ebuild to incorporate these changes? Few general remarks: 1) all references to smalleiffel should apparently become ${PF} 2) html docs should go into html under sandard docs dir (just use dohtml) 3) you may create symlinks into /usr/bin or may just drop that, as you seem convinient. If you do, please note name mangling of the "compile" binary into "se-compile". Having a "compile" executable in /usr/bin is a *bad* idea. Thank you again for your time and involvment! George
Created attachment 5713 [details] smarteiffel-1.0_beta5.ebuild New upstream version. Technically FHS-compliant now. Minor clean ups here and there.
Created attachment 5714 [details] ChangeLog Here's a ChangeLog too. :)
Created attachment 5860 [details] smarteiffel-1.0_beta5.ebuild An updated version of the ebuild. Fixed a few bugs (see ChangeLog). Hopefully everything should work fine now.
Created attachment 5861 [details] ChangeLog New ChangeLog. "ChangeLog" and the latest "smarteiffel-1.0_beta5.ebuild" are all the files you need. All the files/* things that the older ebuilds used are no longer required.
Hi Steven. Thanks for your update. Now this is looking much better! ;) I have somewhat cleaned-up the ebuild (spaces should have been the tabs, I also somewhat simplified the first sed in src_compile) and committed it. Please test. The ebuild is keymasked at the moment. WRT the issue with source name: I mangled the name of source to include version info and uploaded mangled .tar.bz2 file to get it mirrored. Basically its "central" location will be ibiblio.org and we will not be hit when package authors silently replace the source on their site with a new version. George
Thanks for this great ebuild! Some notes/ideas... 1) Please use this instead of "make automatic": -------------------------------------------
Thanks for this great ebuild! Some notes/ideas... 1) Please use this instead of "make automatic": ------------------------------------------- ebegin "Compiling install-program" gcc ${CFLAGS} -o install install.c eend $? einfo "Now running the install-program..." ( echo yes echo no echo UNIX echo gcc echo ${CFLAGS} echo yes ) | ./install -interactive ------------------------------------------- 2) Please use "/usr/lib/SmartEiffel" instead of "/usr/lib/${PF}", so we don't need to recompile all extra modules everytime SmartEiffel is upgraded... 3) Please also install "misc" and "tutorial" in /usr/share/doc/${PF}/! Thanks again! // Per Wigren
Created attachment 5885 [details] smarteiffel-1.0_beta5-r1.ebuild The ebuild worked fine. But here's an improved version. :) This one has CFLAGS support - thanks to our friend Per Wigren - and uses the "doc" USE-flag for documentation installation. See the ChangeLog that follows for more details.
Created attachment 5886 [details] ChangeLog
Hint: beta6 is released! ;-)
One more thing, please don't rename the compiler "se-compile" instead of "compile" because it breaks ALL of the extra stuff like Gobo, ePOSIX etc... I'm currently making ebuilds for a lot of dev-eiffel/ stuff and these ebuilds will expect the compiler to be named "compile"... Otherwise I'll have to change all configure/bootstrap-scripts which will be maintainance hell...
bah.. Gobo doesn't compile with smarteiffel, but it compiles fine with smalleiffel 0.74... About all other eiffel-packages require Gobo, so I say we go with smalleiffel until packages are upgraded to support smarteiffel! I attach an ebuild for smalleiffel 0.74 which is called "smarteiffel" and uses the same paths so the later upgrade to smarteiffel will be easy,,, In the meantime smarteiffel should be masked...
Created attachment 5959 [details] dev-lang/smarteiffel/smarteiffel-0.26.0.74.ebuild SmallEiffel 0.74 ebuild named SmartEiffel for easier future upgrade.
SmartEiffel 1.0 is out: <http://smarteiffel.loria.fr/> Ebuild needed.
I will update the ebuild to 1.0 soon. Hopefully later today! Hopefully we will also soon see updated releases of GOBO, ePOSIX and the other packages that breaks with SmartEiffel but works with SmallEiffel.. (SmartEiffel has corrected some things to be more standards-compliant, and it breaks a few things.. Not much though..)
Here is a IMHO great ebuild for smarteiffel 1.0! Things I changed: * Support for TinyCC as default compiler using "tcc"-useflag. * Added a SE_DIR environment-variable so all extra-packages can depend on it. * Changed SE_DIR to /usr/lib/SmartEiffel, because that is the default dir if the SmartEiffel-variable is not set, and a few 3rd-party-packages expect it. * Don't rename compile to se-compile anymore! This breaks ALL 3rd-party-packages! * SmartEiffel is now distributed with versionnumbered filenames so there's no need to rename+mirror anymore! ;)
Created attachment 6344 [details] dev-lang/smarteiffel/smarteiffel-1.0.ebuild Please commit this!
Created attachment 6349 [details] Small update: dev-lang/smarteiffel/smarteiffel-1.0.ebuild Use SmartEiffelDirectory instead of SE_DIR as the global env-variable, because that seems to be standard. (Gobo expects it for example)
Hi Per, Steven, Jason. Thanks for the ebuild and the info! I have tested and committed the ebuild, please test. Per: You specified tcc dependency as >=0.9.14, however there is only 0.9.8 in the portage at the moment and it apparently has some trouble compiling smarteiffel. I tried emerging tcc-0.9.14 by renaming latest ebuild, however this seems to be more involved than that. Therefore I commented out all tcc specific stuff from smarteiffel ebuild for the moment. It shell be added back when tcc gets updated. BTW, do you have a working ebuild for tcc-0.9.14? Could you please submit it? I did not see it among my bugs or on bugzilla. Thanks! George
Oh, Ok, seems you just did it, while I was processing smarteiffel :). Please disregard the last part of previous message. George
Hi Per. Short update on the situation with this ebuild: I just committed your tcc-0.9.14 ebuild. However there was no "official" decision made on tcc support in portage yet. Therefore I will refrain from uncommenting related lines in the ebuild for some time. Fortunately it doesn't seem to be so crytical in this case - smarteiffel does not seem to require too much compilation. Realistically speaking though I can hardly expect tcc decision be made in the few weeks left of this year - we are trying to get 1.4 ready and are concentrating on the most basic features that have to be finished first. tcc, while being a really nice addition, does not seem to be crytical, so I suspect it will be taken care of en large as soon as we are done with 1.4. I will temporarily close the bug for now with resolved/later. Please remind me if I don't reopen it after 1.4 is released (or after New Year, whichever happens first), or even reopen it yourself ;). George
db fix
