|
Description
Donald Giuliano
2003-10-25 06:49:56 UTC
Created attachment 19767 [details]
GEMPAK ebuild tarball (includes several supporting files)
This tarball attachment contains the GEMPAK ebuild, as well as several
supporting files which are used in the build process.
Created attachment 20143 [details]
**REVISED** GEMPAK ebuild tarball (with supporting files)
Revised the ebuild to change the motif dependency from lesstif to openmotif
at
the suggestion of Stonie Cooper. This fixes the GUI issues I had been having
with nmap2 and garp (not previously mentioned).
Also, made lesstif a != dependency as a result, as well as gcc-3.3, since
the
f77 compiler for gcc-3.3 is reported (also by Stonie) as being broken at
present.
Thanks Stonie!
This is a valuable entry to the portage tree; please make Don's ebuild part of the standard *stable* gentoo installation. Stonie Cooper It would be very much appreciated if, in the future, you would attach files as plain-text, with the ebuild and supporting files as separate attachments. I'm taking a look at them now. OK, I'll be sure to submit the files as individual attachments from now on. I thought I was making things easier by submitting it as a single tarball, but I guess not. :-\ Thanks for pointing that out. Also, in just a moment I'll be submitting an updated ebuild and change the gui.c supporting file into a patch (I'd overlooked this before!). Created attachment 20147 [details]
Updated Ebuild for gui.c patch
Created attachment 20148 [details, diff]
gui.c patch file
Created attachment 20149 [details]
**REVISED** Updated Ebuild for gui.c patch
Fixed an oops in the ebuild that caused the patch to not apply at all
(incorrect filename).
This ebuild could use a little work. Take a look at the savagedemo ebuild
for a rough idea of how to force fetching. It should use RESTRICT="fetch"
and messages should be in pkg_setup(). Unpacking and pre-compilation things
should be done in src_unpack().
As for the run_make.bash, that's really bad. You can just export the variables
in the ebuild, or preferably set them in src_compile() as local variables
if that works. Also as I was hinting earlier, the compilation needs to take
place in src_compile() and the installation (e.g., make install and other
things) in src_install().
Try to get any version-number-specific things out of the ebuild if possible
(VERSION=5.6.j). Instead see if you can figure out a way to get that from
PV and some bash. 'man bash /Parameter Expansion' may prove helpful in this.
MY_PV="${PV/[a-z]/.[a-z]}" seems like it might work out fairly well.
The dependency on !=sys-devel/gcc-3.3 is pretty ridiculous. Could you please
test using the latest ~arch gcc in portage to see if g77 is broken as suggested?
I notice that even though you're attaching as single files, the type is still binary. Make sure you change the type to text/plain. Also when making diffs, please use diff -urN. Oh yeah. I was reminded that the fetching message should go in pkg_nofetch(), not pkg_setup(). I confused the two. OK, I'll work on these issues. I also have a question for you. When I'm done making modifications to the ebuild and I repost the ebuild/patch, should I also repost all the other supporting files individually so as to make them more easily available? Or should I just leave things as they are, only providing updated files as necessary? Thanks for your patience. It would be helpful for all the files (not including digest, Manifest or the run_make.bash which is going to disappear) to be posted individually as text/plain. Then you can obsolete individual files as necessary if they change. MY_PV="${PV:0:${#PV}-1}.${PV:${#PV}-1}" might be even better. mr_bones_
suggested it.
Many thanks for the bash tip, that works great. I have the issues you raised resolved, and am in the process of testing the gcc-3.3 compatibility. I'll be posting updated files as soon as I finish up. OK, the code for one of the GUI applications (garp) is in fact incompatible with gcc-3.3 due to its use of now-obsolete header files that gcc-3.2 would still accept. However, I do not see this as sufficient reason to ban gcc-3.3, esp. as it is simply a matter of writing a small patch to make Garp gcc-3.3 compliant, and everything else seems to work fine. Therefore, I am uploading the updated files, and believe that this ebuild is ready to go. The Garp problem with gcc-3.3 is, in my opinion, almost a non-issue, though I'll try to fix it as soon as I can. If there are any other problems with the ebuild, please let me know and I will take care of them. Created attachment 20158 [details]
Gemenviron.bash: GEMPAK configuration file
The Gemenviron.bash file is simply a bash version of the main GEMPAK
environment configuration file.
Created attachment 20159 [details]
Gemenviron.tcsh: GEMPAK configuration file
The Gemenviron.bash file is simply a tcsh version of the main GEMPAK
environment configuration file.
Created attachment 20160 [details]
Makeinc.common.1: Part 1 of the Makeinc.common config file
The first part of the Makeinc.common file, the purpose of splitting it up
like
this is evident in the ebuild.
Created attachment 20161 [details]
Makeinc.common.2: Part 2 of the Makeinc.common config file
The second part of the Makeinc.common file.
Created attachment 20162 [details]
gemdatadir_create: Shell script for creating skeleton gem data dir
This shell script automatically creates a skeleton GEMPAK data directory
tree.
Created attachment 20164 [details, diff]
gui.c.patch: Patch file for fixing hard-coded bitmap paths
The Garp file gui.c ($GEMPAK_SOURCE_HOME/comet/garp/gui/gui.c) has the paths
to
a number of bitmaps hard-coded into the source. This patch changes the paths
appropriately given the location the ebuild installs the package to.
Created attachment 20165 [details]
unset_vars: A list of all variables in the Gemenviron file
This file contains a list of all the variables present in the Gemenviron
file.
It is necessary to unset all of these variables before attempting to compile,
as otherwise they will cause problems with the build process.
Created attachment 20166 [details]
gempak-5.6j.ebuild
This is the GEMPAK ebuild.
Comment on attachment 20164 [details, diff]
gui.c.patch: Patch file for fixing hard-coded bitmap paths
Marked gui.c.patch as being, in fact, a patch.
One additional note: I neglected to delete the gcc-3.3 anti-dependency, though it is commented out. OK I've been looking through this some more. I reworked the ebuild (attached
shortly).
Things left to do:
1) Changing the Makeinc.common thing to a sed. It's just cleaner. The general
idea is to make the number of files in addition to the ebuild as minimal
as reasonable.
2) Fix a couple of errors compiling, presumably a header problem. Log of
errors coming shortly.
3) Stop installing everything! Source files should not be installed! Cause
'make install' to install to ${D}/usr/gempak instead of that nasty cp -Rf.
If absolutely necessarily, we could delete all the Makefile-type things,
*.c, *.h, *.o files, but that is poor.
4) See if the 'ebuild config' part actually works. It should, but it needs
verification.
5) Make sure it works...anything else we didn't think of.
Created attachment 20227 [details]
gempak-5.6j.ebuild
Created attachment 20228 [details] Errors from attachment #20227 [details]. Created attachment 20229 [details, diff]
gui.c.patch version 2
Created attachment 20230 [details]
gempak-5.6j.ebuild
Slight modifications to reduce verbosity on unpacking, and a couple of other
things.
OK... 1.) Easy, I thought about doing it before and should have. Silly me. 2.) Just so I know, are you using gcc-3.3? I've never had that problem with gcc-3.2, and would like to make sure it's not something odd that I haven't seen. I'll see if I can fix it. 3.) The only reason I left it like this was because conventionally GEMPAK is installed as I did it--agreed, it is very unclean and poor practice. Thus I'll see what I can do about it. GEMPAK is not a clean application suite by any stretch of the imagination, but you're right, I can make the typical install much cleaner. 4.) I like what you did with pkg_config(), that's pretty cool. I'll check it to make sure it works. 5.) Any other problems I run across I'll take care of. $ gcc --version gcc (GCC) 3.3.2 20031022 (Gentoo Linux 3.3.2-r2, propolice) Alright, I've been working on your suggestions and here's what I have: 1.) Done. 2.) I haven't found a solution for this. I've searched on the web quite a bit, and the only suggestions I find are "change <varargs.h> to <stdarg.h> in your source files", which of course we've already done. Thus Garp still doesn't work with gcc-3.3. 3.) It would be inadvisable to attempt to get the Makefile(s) to install everything to /usr/gempak. There are a large number of files (configs, maps, tables, and quite a bit of other stuff) which the Makefiles never touch that are absolutely necessary, and would not be transferred into /usr/gempak without doing several "cp -Rf" commands anyway. I've opted for removing all the unnecessary files first and then doing a "cp -Rf" on the remainder. It's not pretty, but I consider it to be the "least ugly" solution. 4.) pkg_config() does not appear to want to accept command-line arguments. I tried searching through other ebuilds that have a pkg_config(), as well as looking through the forums, but I couldn't find any packages that wanted to accept arguments for the ebuild config process, or anyone that wanted to do something similar. Should I try posting to the forums about this? 5.) I've made a couple small changes to the ebuild other than this, but nothing particularly spectacular. Basically I just versioned it up to gempak-5.6k (I'd avoided it earlier because I'm always paranoid about moving up to a different gempak version, and I knew I had 5.6j working correctly on my machine). Also, I commented out the obsolete header update (see below). -------------- Current Status -------------- With gcc-3.2, everything seems to work flawlessly, so long as varargs.h is used instead of stdarg.h. With gcc-3.3, everything but Garp installs and works fine (I tried using the gcc-3.2 varargs.h in place of stdarg.h as someone suggested online, but that did not work). Since Garp is really a very small part of the GEMPAK suite, gcc-3.3 is still experimental anyway, and practically everyone installing this will be doing so in a stable environment (i.e., stable gcc), I propose just placing an einfo comment at the end of the install notifying gcc-3.3 users that Garp does not currently function properly. Then as soon as Garp is updated to account for the new version of gcc, the problem (small as it is anyway) will simply go away. Created attachment 20245 [details]
**Revised** Makeinc.common
Created attachment 20246 [details, diff]
gui.c.patch -- Changed paths to /usr/gempak
Created attachment 20247 [details]
gempak-5.6k.ebuild
Is is possible to do all the deletion before needlessly copying it over to
${D}?
2) Still needs some looking into. I haven't been able to track it down.
4) Fixed. looks like GEMDATADIR was getting set somehow, so I changed the
variable name.
5) Since obsolete headers aren't only in garp, I re-added the update for
>=gcc-3.3.
Also some general cleanup and update to 5.6l, which they versioned 5.6l.1
so I added EXTRAVER near the top.
Created attachment 20504 [details]
gempak-5.6l.ebuild
There's absolutely no reason to copy the files and then delete them, so I fixed that. Also, I added in an ebegin for copying the files, and added in a check for the existence of the data directory in pkg_config(). Created attachment 20508 [details]
gempak-5.6l.ebuild
Updated the ebuild as described above.
Created attachment 20509 [details]
gempak-5.6l.ebuild
Noticed I had indented a couple things improperly.
Created attachment 20511 [details]
gempak-5.6l.ebuild
Switched DEPEND and RDEPEND, pulled gcc checking and variable unsetting/setting
out to functions to reduce code duplication, moved a sed up to src_unpack(),
made the installation verbose, changed some echos to einfos, and a few other
tweaks.
Any idea why a 'sed -i' doesn't work on the Makeinc.common? It acts as if NAWIPS isn't set if I try to do that. The Makeinc.common I've included as an attachment includes a number of changes
to it as compared to the original one, and NAWIPS must be the first variable
defined in the file. I'm not sure if this is what you were asking, though.
Also, I tried making a patch from Makeinc.common.gentoo to Makeinc.common
(similar to the gui.c.patch file), and for whatever reason GEMPAK will not
compile correctly using the patch, even though I verified that the patched
Makeinc.common file in ${S}/config is, in fact, completely correct after
a sed -i has been applied to it, and identical to the Makeinc.common file
generated by the working method currently used in the ebuild! This makes
no sense to me at all, but that's what is happening. I'm attaching the Makeinc.common.patch
file if that helps at all.
Created attachment 20557 [details, diff]
Makeinc.common.patch
To clarify my earlier comment, the "original" Makeinc.common file I refer to is the one in the gempak tarball, and the Makeinc.common attachment is the one marked as **Revised**. OK, I guess we're stuck copying over instead of just applying a patch, because it mysteriously won't work. The last thing we need to look at is those compilation errors on gcc 3.3. It would be really nice to track those down and provide a patch. I've done a little more research into the gcc-3.3 issues, and discovered that the problem lies in the way variadic functions (ones accepting a variable number of variables) have historically been handled in UNIX. The ISO-defined way of doing it is with stdarg.h, the older way of doing it in gcc was with varargs.h. There are a couple differences with regards to how variadic functions are defined that are causing the errors. Unfortunately, wprint() is such a variadic function, and is spread throughout the code in a number of locations--I'm not totally sure exactly how it all works, but I think wprint() might be something of a proxy for vsprintf() since vsprintf() is not defined on older BSD systems, as noted in the comments in comet/garp/gui/log.c. You can read more about it at the following URL: http://docs.linux.cz/glibc-manual/libc_35.html#SEC685 Nice find. Looks like if you fix va_start and get rid of va_dcl so it uses the new form instead of the old form things might work. I'm not sure why there was no error in ./comet/garp/gui/status.c. Looks like a bunch of other files that use va_start might have it dually defined from a quick grep, one in each format. Try 'grep -r va_start ./' (and va_dcl) from the top of the source and see if you can figure out how to fix it. Or you could just wait until a fixed version is released. However I want this to work on gcc 3.3 before it's in portage, because although it's not stable now it may be anytime. OK, I'll take a closer look at this issue--I hadn't realized gcc-3.3 was that close to going stable. I'll post the results of my investigation in a few hours. I don't know the status of gcc 3.3, that's my point. Regardless, GEMPAK will need to be safe for >=3.3 at some point. You could try contacting the developers and pointing out that garp is broken on new gcc. Good point. I admire your attention to detail...this type of approach is what makes Gentoo the best Linux distribution out there, in my opinion. As far as this issue is concerned, I think I have solved it and am recompiling now. After examining some of the other files which had it dual-defined, I believe the solution to be very trivial and am testing it now. Alright, I've got it working. I'll be attaching patches for log.c and gprint.c, as well as an updated ebuild that only applies the patches if for gcc-3.3 or greater. Created attachment 20564 [details, diff]
gprint.c.patch
Created attachment 20565 [details, diff]
log.c.patch
Created attachment 20566 [details]
gempak-5.6l.ebuild
Sorry, I've been distracted by other things. I'll get to this again after Thanksgiving weekend. That's what I figured, esp. after I saw this week's GWN stuff relating to freedesktop.org, etc. Thanks for the update! OK, I'm back to this. You redid the whole gcc_check() by hand for your check, so I'm changing that. Also, does this stuff actually break gcc-3.2? I thought the old version was deprecated and the new worked in 3.2, but perhaps not? Presumably it's a good idea to actually have the stuff be runnable after install. I've never gotten to that point before so haven't run into this yet.
Something like this in src_install():
echo "BINDIR=/usr/gempak/bin/linux" >> ${T}/10gempak
insinto /etc/env.d
doins ${T}/10gempak
ought to work...
Created attachment 21753 [details]
ebuild with gcc_check fixes, but lacking env.d file.
Created attachment 21754 [details]
ebuild with env.d stuff.
Good call with the gcc-3.2 issue, you're absolutely right about that. I compiled/tested it just to make sure, and it works fine when using gcc_check "3" "2".
As far as the /etc/env.d stuff is concerned, it must be noted that in order for GEMPAK to function, the Gemenviron.{bash,tcsh} file must be sourced, as it is loaded with environmental variables that need to be set. I tried copying Gemenviron.bash to /etc/env.d/10gempak, but it didn't work, and I got the following error when running env-update:
!!! Invalid token (not "=") NAWIPS
!!! Parsing error in /etc/env.d/10gempak
Any ideas?
Geez, sorry about the lack of returns in the previous comment...here it is again,
this time in a more screen-friendly format:
Good call with the gcc-3.2 issue, you're absolutely right about that. I
compiled/tested it just to make sure, and it works fine when using
gcc_check "3" "2".
As far as the /etc/env.d stuff is concerned, it must be noted that in order for
GEMPAK to function, the Gemenviron.{bash,tcsh} file must be sourced, as it isGood call with the gcc-3.2 issue, you're absolutely right about that. I compiled/tested it just to make sure, and it works fine when using gcc_check "3" "2".
As far as the /etc/env.d stuff is concerned, it must be noted that in order for GEMPAK to function, the Gemenviron.{bash,tcsh} file must be sourced, as it is loaded with environmental variables that need to be set. I tried copying Gemenviron.bash to /etc/env.d/10gempak, but it didn't work, and I got the following error when running env-update:
!!! Invalid token (not "=") NAWIPS
!!! Parsing error in /etc/env.d/10gempak
Any ideas?
loaded with environmental variables that need to be set. I tried copying
Gemenviron.bash to /etc/env.d/10gempak, but it didn't work, and I got the
following error when running env-update:
!!! Invalid token (not "=") NAWIPS
!!! Parsing error in /etc/env.d/10gempak
Any ideas?
OK, whatever, I don't know what I did in the text box on the webpage, but sorry for the messy comments. I'm not going to clutter the bug report page even more attempting to re-post the comment again. Created attachment 21767 [details]
env.d file
Created attachment 21768 [details]
updated ebuild
einfo is still outdated, refers to Gemenviron files. env.d file has datadir hardcoded. We might want to hardcode it to somewhere other than /data/gempak (/usr/gempak/data?) both in env.d file and auto-create it there as well instead of having that configurable. OK, I think making GEMDATA be /usr/gempak/data sounds fine, especially since anyone using a different location can simply symlink it there. I've updated both the ebuild and env.d file to reflect this change, and also fixed a couple typos in the env.d file. Created attachment 21779 [details]
Updated Ebuild
Created attachment 21780 [details]
Updated env.d File
Created attachment 21781 [details]
Updated Ebuild
Fixed problem with hrs & hds symlinks in the ebuild.
Created attachment 23219 [details]
Update Ebuild
Fixed typo in pkg_postinst(), and added wording encouraging people with
pre-existing data directories to symlink it to /usr/gempak/data.
I just checked in 5.6m with a few changes, keyworded ~x86 only. Let me know how it works and whether it works on other arches. OK, I've been using this for over a week now with no problems whatsoever. The only thing I really noticed is that the name of the file downloaded from Unidata is different from the filename expected by the ebuild in the distfiles directory, so I had to change the filename myself. I'm not sure how the gempak ebuild works on other arches, because I don't have administrative access to any non-x86 machines running gentoo. At any rate, on x86 machines gempak seems to be working perfectly. Thanks again for your help. That's odd, the filename matches perfectly here.
donnie@supernova molden $ emerge gempak -fp
Calculating dependencies ...done!
>>> md5 src_uri ;-) gempak_upc5-1.6.m.tar.gz
>>> md5 src_uri ;-) gempak_upc5-1.6.m.tar.gz
Shouldn' that be: gempak_upc5.6.m.tar.gz instead of: gempak_upc5-1.6.m.tar.gz Nope, because that's the name of the tarball I downloaded. The only source file I see on there right now is gempak_upc5.6.m.tar.gz. Perhaps they changed the filename at some point? |
