Please find attached hla-1.59.ebuild. HLA is a higher level assembly language compiler relying on as and ld to handle linking and assembling. It's a good tool for people just learning assembly and relied heavily upon in many corporations. I suggest dev-lang/hla. This ebuild relies on binutils. Reproducible: Always Steps to Reproduce: 1. 2. 3.
Created attachment 20318 [details] hla-1.59.ebuild This ebuild requires a specific tarball that I made to function properly.
Created attachment 20319 [details] hla-1.59.tar.gz The tarball that contains the HLA source and binaries.
HLA originates from url http://webster.cs.ucr.edu/AsmTools/HLA/dnld.html HLA recently released v1.62, released 3/6/2004 The HLA is a High Level Assembler which is used and detailed within the open book "Art of Assembly Book" at url http://webster.cs.ucr.edu/ This open & published book on Amazon includes some really good reviews. I wonder if this open book should be included as "Additional Documentation" via the "doc" USE variable? Suppose to be some really good stuff here with HLA and this book, yet, emerge -s hla shows null :-/
Check the link in forum for the ebuild files. I am contacting the author of the language to get some help to address the library build problem. http://forums.gentoo.org/viewtopic.php?t=117069&highlight=hla The ebuild hla (compiler) along is working. Need to iron out some issues with lib ebuild.
Created attachment 27660 [details] HLA compiler ebuild for version 1.62
I have not tested the latest 1.62 ebuild submission. I have tried to compile HLA from source and noticed that while compiling HLA code (ie: hw.hla), the hla/hlaparse executables were having problems finding the includes/libs (whether or not I specified them via command line or via shell variables). The only way I've been able to get HLA to compile *.hla code is by placing the libs/includes into the non-standard location that the author recommends install HLA (ie /usr/hla instead of /usr/local or /usr/bin/hla, etc) -- he is currently looking over this bug that i've submitted to him.
ok. i've just test this ebuild and it's missing the LIBS & INCLUDES for hla to work properly. ie /usr/include/hla/*.hhf & /usr/lib/hla/hlalib.a Here's whats listed in the pre-made hla binary available from the author: /usr/hla/hla /usr/hla/hlaparse /usr/hla/hlalib/hlalib.a /usr/hla/include/*.hhf /usr/hla/inclde/os/*.hhf The above libs/includes can be found in hla.tar.gz.tar but, to not, it has a precompiled hlalib.a lib file :-( <-- this is the binary file of hla. And, the Include & Lib locations need to be exported via a /etc/env.d/ file. ie: /etc/env.d/20hla hlalib=/usr/hla/hlalib/hlalib.a hlainc=/usr/hla/include
ok. i've just tested this Ebuild and it's missing the LIBS & INCLUDES for hla to work properly. ie /usr/include/hla/*.hhf & /usr/lib/hla/hlalib.a Here's what's listed in the pre-made hla binary available from the author: /usr/hla/hla /usr/hla/hlaparse /usr/hla/hlalib/hlalib.a /usr/hla/include/*.hhf /usr/hla/inclde/os/*.hhf The above libs/includes can be found: http://webster.cs.ucr.edu/AsmTools/HLA/HLAv1.62/hla.tar.gz It is the pre-compiled version with a precompiled hlalib.a lib file :-( Basically, what I propose for a temporary work-around is to just copy over the *.hhf files from here and maybe also hlalib.a (if the source cannot be found for it). I've emailed Randall Hyde on this issue and he said he was going to tar/zip up the hlasrc with the includes, but this was last week. And, the Include & Lib locations need to be exported via a /etc/env.d/ file. ie: /etc/env.d/20hla hlalib=/usr/hla/hlalib/hlalib.a hlainc=/usr/hla/include I've encountered a small issue the lib/include locations. hla expects to find the libs/includes @ /usr/hla/includes no matter what you define the variable paths too. seems like something is hard-coded here. And to think, I wonder if the culprit for the hard-coded locations is the precompiled hlalib/hlalib.a! I have also emailed Randall Hyde on this issue and he was going to review the problem last week. Again, have yet to hear anything from him on this.
Created attachment 27719 [details] Updated ebuild to install include files from the binary package. Based upon feedback from roger, I have made some update to the ebuild to get the include files from the binary tarball. It also include changing the include path to /usr/include/hla
Created attachment 27720 [details] HLA library ebuild for version 1.62 This one depends on attachment 27719 [details]. This ebuild build all libhla.a and install it to /usr/lib/hla
Minor fixes need. In /etc/env.d/20hla, the library name is defined inconsistency with the hlalib ebuild. If you prefer hlalib.a, then change the hlalib ebuild, otherwise change the /etc/env.d/20hla instead.
First, the naming of the packages -- I'm guessing the following: dev-lang/hla/hla-1.62.ebuild dev-libs/libhla/libhla-1.62.ebuild I got some interesting results with qpkg -l hla & qpkg -l libhla $ qpkg -l libhla dev-libs/libhla-1.62 * CONTENTS: /usr /usr/lib /usr/lib/hla /usr/lib/hla/hlalib.lib /usr/lib/hla/hlalib.txt /usr/lib/hla/t.exe /usr/lib/hla/makefile.debug /usr/lib/hla/makefile.linux /usr/lib/hla/file.txt /usr/lib/hla/makefile /usr/lib/hla/consoleTest.hla /usr/lib/hla/delete.bat /usr/lib/hla/libhla.a /usr/lib/hla/makefile.fasm (I don't think the ^^ makfiles ^^ are suppose to be there -- according to Randall's binary, only hlalib.a needs to be there. ;-) A minor issue is the "updated version of hla-1.62.ebuild" should also depend on libhla-1.62.ebuild -- obviously since neither will run correctly without the other? Not to make things more difficult since you took the time to already create two ebuilds, but since binary files created with hla are runable without the libhla, it might not make sense to create two ebuilds(?) dunno. i'll leave this decision to you ;-) Lastly, the hard-coded fixed location of hla's includes (probably residing within teh precompiled hlalib.a), to avert, I did the following: # mkdir /usr/hla # ln -s /usr/include/hla /usr/hla/include I do not know how this can be done with an ebuild file as I've found the ebuild fails when sandbox is used and it encourters 'mkdir' command. Since enviromental variable assignments do not work with hla, we're pretty much stuck waiting for a fix from Randall to fix/recompile hlalib.a as it is not open source?? Or, to go against the filesystem layout of the distro and temporarily do /usr/hla? As I have re-re-re-verified this bug, it appears to be a problem with the INCLUDES location (hlainc=|*.hhf files)only and not hlalib=|hlalib.a ... ok. i'm breaking for now. removed a precompile "hw" using hw.hla and now it borks. it appeared to be compiling fine until I removed the binary "hw"... prob' just going thru the linker instead of hla. arggh RANDALL!!!! oh well. my vote is to just install to /usr/hla for the time being and let Randall have his way. This would cut down on a mess of (hopefully temporary) hacks & bit banging. clean-up libhla-1.62.ebuild by only installing hlalib.a (if i'm correct on this) or combine this one liner with/into the hla-1.62.ebuild (use a multiple url w/i SRC_URI, unzip/untar, & cp over the hlalib.a file) ???
Created attachment 27747 [details] HLA library ebuild for version 1.62 (udpated) Ok, I have cleaned up the "installation" part so only one file is installed, libhla.a to /usr/lib/hla. Regarding whether it should be two ebuilds or one, here is the rationale I have when I do the ebuild. a) hla can be build correctly without hlalib, even though because it is written in C (not HLA) so things are compiled fine. b) hlalib needs to have hla and hlaparse to exist in the environment prior to compile anything useful. so it is obvious that it is be depending on hla. c) the reason why I have separate files because i could figure out (still n00b) in ebuild on how to refer hla, hlaparse that was compiled but not installed in the system. And i think it is clumsy method to 'sed' all the makefile just to fix hla and hlaparse with absolute path (in the build environment). And I am not sure if this "temporary hardwired path" is going to effect the final build of hla and hla library. So i opt'ed to stay out of this.
BTW, the HLA library compiled from ebuild should have the correct HLA include path, /usr/include/hla since the library is recompiled. Not using the one in binary package at all.
the reason why I have separate files because i could figure out (still n00b) in ebuild on how to refer hla, hlaparse that was compiled but not installed in the system. I meant: I couldn't figure out Sorry for the typo
I just seen a note on the HLA mailling list concerning that HLA has been upgraded to 1.63. Randall makes note that he just hasn't changed the filename link to show "1.63", but it is the "1.63" version. I have no idea if the lib/includes location variable has been fixed. I do know that it was acknowledged by him somewhat. :-/ (ie, HLA will only function if installed to /usr/hla and not while installed to /usr/include/hla or /usr/lib/hla
also just noticed when upgrading to 1.63 here, that the files have no versioning numbers, as such, the packaging server could easily confuse 1.62 source code for 1.63 source code (and vice versa). Am I correct here? I did notice that for versioning, teh author is using folder names for versioning.
Just a quick heads-up. I was able to compile the hla-1.63, but not libhla-1.63. libhla (or hlasrc), encounters an error when compiling. I've posted to the HLA mailling list. I've also made note on the mailling list that there is now hlasrc.tar.gz, only a hlasrc.zip within the AsmTools/HLA/HLAv1.63/ folder. (I hacked around this and created a quick tarball, which I then ran into a compile problem with the hlasrc source code.) ...stuck for now...
There appears to be a missing ")" in the hlalibsrc-1.63 source code, to further explain, below is a quick diff of orig & fixed code. The HLA mailling list has been notified. --- misc/env.hla 2004-05-07 18:13:14.247625000 -0400 +++ misc/env.hla.fixed 2004-05-07 18:14:36.450128320 -0400 @@ -102,7 +102,7 @@ tstralloc( 4096 ); mov( eax, dest ); - if( env.get( envVar, (type string eax) ) then + if( env.get( envVar, (type string eax) ) ) then str.a_cpy( dest );
also, the /etc/env.d/20hla has an incorrect filename!!!! Please Squish ASAP! (a quick handwritten diff) --- /etc/env.d/20hla 2004-05-07 17:07:39.000000000 -0400 +++ /etc/env.d/20hla.fixed 2004-05-07 20:46:18.925073288 -0400 @@ -1,2 +1,2 @@ -hlalib=/usr/lib/hla/hlalib.a +hlalib=/usr/lib/hla/libhla.a hlainc=/usr/include/hla (I also found a bug in my code when debuggin my *.hla code -- as to why the hla env variables were not being used.) Everything here now works!!!!
Take note, the source files will no longer be in tarballed. They will be zipped (.zip) and only the pre-made binaries will be tarballed (tar.gz) (word from Randall on the mailling list -- so we just need to make the modifications to the ebuilds to use zip decompression from now on in hlalibsrc.)
once last note before I attempt createing a hla-1.63.ebuild, I've just verified that there are no runtime deps for HLA created code as the binary is true machine instructions. So no need for seperate packages (hlalib, etc). This was my thinking as to recommending seperate packages. I though hlalib was a runtime dep requried for executing HLA created binaries. :-/
ok. spent some time and have completed packaging 1.63. I could not figure out either how to package these two into one ebuild file. I noticed your comment first but didn't understand it until now. Anyways, I've made several notes within the 1.63 ebuild files. I've also created Changelog files ..and hlalibsrc-1.63 also has a fix/patch to go along with it. Anybody up to packing hla docs? ie the AOA book & examples ;-) ...actually, could probably use a USE flag with these extra files.
Created attachment 31217 [details] hla-1.63.ebuild
Created attachment 31218 [details] hla-1.63.ebuild New release
Created attachment 31220 [details] Changelog for dev-lang/hla Changelog for dev-lang/hla
Created attachment 31221 [details] libhla-1.63.ebuild
Created attachment 31222 [details] Changelog for dev-libs/libhla Changelog for dev-libs/libhla
Created attachment 31223 [details, diff] Patch to fix a syntax error within the hlalibsrc-1.63 Patch to fix a syntax error within the hlalibsrc-1.63 This file/patch goes into the files/ folder for dev-libs/libhla !!!
FYI According to a recent article, HLA Version 2.0 will be soon released. HLA is currently at "version 1.76".
Re-assign.
Either find a maintainer, or if you want to maintain it yourself, feel free to reopen and join project sunrise, details here: http://www.gentoo.org/proj/en/sunrise Thanks. WONTFIX.
Created attachment 322250 [details] hla-bin-2.16.ebuild Hmm, so nobody is caring about it since 2007? This is an ebuild for the binary version of HLA 2.16 provided on its official website (hlalib included). Not throughly tested, I don't understand much about the "best practices" for ebuilds, and I'm quite unsure about its dependencies. As HLA does not have a 64-bit version, on amd64 it's still the 32-bit version. An ebuild compiling it from source code will be attached shortly.
Created attachment 322258 [details] hla-2.16.ebuild An ebuild that compiles hla-2.16. Known issues: 1. It has not been tested on any arch but amd64. Nor did I test if hla compiles things correctly. 2. It uses dynamic linking instead of static linking (which is the default in hla Makefile). Unsure if that would cause any issues. 3. sys-devel/flex probably needs to be patched to increase maximum rule limit to compile hla. Not sure if there's any better ways: /etc/portage/env/sys-devel/flex --- pre_src_prepare() { sed -i 's/MAXIMUM_MNS 31999/MAXIMUM_MNS 65535/' flexdef.h || die } --- 4. HLA has no official 64-bit version and one of its ASM source file contains 32-bit only code. It thus compiles 32-bit version on amd64. 5. hla depends on hlalib to build, hlalib depends on hla to build, so I use the binary hla to build hlalib, then use the built hlalib for building hla. 6. Does not have a good ebuild style. Did not consider corner cases (like when you have a colon in $WORKDIR, have a slash in $CFLAGS. 7. Respects CFLAGS and CC only incompletely. 8. MAKEOPTS='-jN' may not work as expected. Looking into it...
Looks like a I did some tinkering to get things building and installing correctly, but likely never resolved some issues or working around hla/hlalib's packaging issues. Shortly after working on this ebuild, I picked-up Jonathan Bartlett's "Programming from the Ground Up" book on Assembly language and never really looked back at the custom ASM libs/lang of HLA. Bartlett's book specifically deals with Linux Assembly Language (unlike the other misleading titled Linux Assembly books) and is a good or required read for learning programming. There also doesn't seem to be much activity with the custom HLA custom language (or not as popular as ASM/C/C++), and am guessing most look to Bartlett's book for the (more standardized) Assembly Language practice. If you're interested in Assembly Lang, might also look into KolibriOS, includes source code ... quite fascinating!
Created attachment 322358 [details] hla-2.16.ebuild Revised hla-2.16.ebuild. 1. Should now respect CC, CFLAGS, and LDFLAGS. 2. Added "-Ca" to flex invocation so flex no longer needs to be patched. 3. Parallel make still does not work because it triggers a few bugs.
(In reply to comment #35) > Looks like a I did some tinkering to get things building and installing > correctly, but likely never resolved some issues or working around > hla/hlalib's packaging issues. If I am to separately package hla and hlalib, then I guess there are three pages needed. The user has to firstly emerge hla-bin (required for hlalib to build), then hlalib, then unmerge hla-bin and emerge hla... The situation for HLA 1.x is probably simpler, though. > Shortly after working on this ebuild, I picked-up Jonathan Bartlett's > "Programming from the Ground Up" book on Assembly language and never really > looked back at the custom ASM libs/lang of HLA. Bartlett's book > specifically deals with Linux Assembly Language (unlike the other misleading > titled Linux Assembly books) and is a good or required read for learning > programming. > > There also doesn't seem to be much activity with the custom HLA custom > language (or not as popular as ASM/C/C++), and am guessing most look to > Bartlett's book for the (more standardized) Assembly Language practice. > > If you're interested in Assembly Lang, might also look into KolibriOS, > includes source code ... quite fascinating! Thanks for the suggestions. I guess the Art of the Assembly Language still covers more things (it's two times longer than Programming from the Ground Up"), though. Also, the second edition of the book came on 2010, so it may have some updated info.
HLA (The Art of Assembly Language) is it's own beast. Similar to a frontend to Assembly language. It's compiled programs require the HLA libs to be installed, if my memory serves me correctly. "Programming from the Ground Up" only deals with the raw Assembly Language. I'm guessing, if you continue with this ebuild, you could likely "unpack" the binary hla libs into the /var/tmp/portage folder and then export(?) the hlalib binary executables for the ebuild to build against (... similar to (chain?) building gcc?). This way, you avoid installing & uninstalling the binary hlalib package into the user's system and just install the HLA build from sources.
(In reply to comment #38) > HLA (The Art of Assembly Language) is it's own beast. Similar to a > frontend to Assembly language. It's compiled programs require the HLA libs > to be installed, if my memory serves me correctly. "Programming from the > Ground Up" only deals with the raw Assembly Language. At least, HLA 2.16 generates statically linked executables, working even without hla/hlalib. > I'm guessing, if you continue with this ebuild, you could likely "unpack" > the binary hla libs into the /var/tmp/portage folder and then export(?) the > hlalib binary executables for the ebuild to build against (... similar to > (chain?) building gcc?). > > This way, you avoid installing & uninstalling the binary hlalib package into > the user's system and just install the HLA build from sources. /usr/hla/hla statically link with hlalib, I believe. If I build hla firstly, hlalib.a coming from the binary version would be linked into /usr/hla/hla, instead of a compiled hlalib.a . Looks like hlalib is entirely built with hla itself, so a compiled hlalib.a may have little differences with the hlalib.a coming with the binary version, though.
Created attachment 322428 [details] hla-2.16.ebuild Revised again. Adding /etc/env.d/20hla to set default HLA options to -lmelf_i386 for amd64 users.
