65950 2004-09-30 14:04 0000 [TRACKER] fortran.eclass 2008-07-01 10:56:14 0000 1 1 1 Unclassified Gentoo Linux Ebuilds 2004.2 All All ASSIGNED InCVS P2 enhancement --- 1 ribosome@gentoo.org sci@gentoo.org f.r.bissey@massey.ac.nz masterdriverz@gentoo.org nbigaouette@gmail.com ribosome@gentoo.org 2004-09-30 14:04:17 0000 As spyderous suggested on the gentoo-science mailing list, an eclass to check for the presence of a Fortran compiler would uniformise the way we deal with ebuilds requiring Fortran, and would ease our work. ribosome@gentoo.org 2004-09-30 14:07:02 0000 Created an attachment (id=40807) fortran-check.eclass Just a first draft. Ebuilds need only to inherit the eclass to have a check for a Fortran compiler. If a more sophisticated package setup is needed, the ebuild can override pkg_setup() and call fortran-check_pkg_setup() from there. kugelfang@gentoo.org 2004-09-30 15:06:29 0000 Created an attachment (id=40812) New fortran.eclass - Kugelfang's propsal My proposal... Thoughts ? george@gentoo.org 2004-09-30 15:11:36 0000 Ok, in order to keep the discussion traceable repostim my message to gentoo-science here.. Well, it would be nice if #57396 would be acted upon finally. That would alleviate like 90% of the complaints we are seeing. BTW, even though its CC'd to seemant I'd rather reassign it to the proper party. Whom should it go to if the change is to happen to make.defaults? Having said that I think that having a fortran eclass would be helpfull too. Oh, and I like that 2nd variant (by Danny) better :). George kugelfang@gentoo.org 2004-10-01 05:12:00 0000 Added my version to CVS. It needs some testing now... fortran.eclass features: * need_fortran(profiles) Profiles is a list of possible Fortran Profiles (f77, ifc and f2c atm). * patch_fortran() Searches for Patches that match "${P}-$(basename ${F77})*" and applies them all. * fortran_pkg_setup() This one runs need_fortran(${FORTRAN}. So ebuild only need to set FORTRAN to the list of supported Fortran profiles. No need for pkg_setup in the ebuilds. FORTRAN defaults to "f77". * fortran_src_unpack() Unpacks and runs patch_fortran(). This one can be dangerous with otehr eclasses. E.g. kde.eclass. So fortran.eclass should come very early in inherit. dberkholz@gentoo.org 2004-10-01 09:41:48 0000 ECLASS=fortran INHERITED="$INHERITED $ECLASS" These two lines are unneeded. I'd like to see F77 changed to FC. If not, why? Both are currently in use. In my opinion, it is very likely that anyone using a Fortran compiler will be using the same one for all F##. donnie@supernova /usr/local/gentoo-x86/eclass $ grep FC ../app-sci/ -rl | cut -d/ -f2,3 | uniq app-sci/blas app-sci/blas-config app-sci/blas-reference app-sci/gempak app-sci/gwave app-sci/lapack app-sci/lapack-atlas app-sci/lapack-reference app-sci/molden app-sci/scilab app-sci/udunits app-sci/xfoil donnie@supernova /usr/local/gentoo-x86/eclass $ grep F77 ../app-sci/ -rl | cut -d/ -f2,3 | uniq app-sci/blas-atlas app-sci/blas-reference app-sci/lapack-atlas app-sci/lapack-reference app-sci/scilab app-sci/acml app-sci/staden kugelfang@gentoo.org 2004-10-01 14:22:58 0000 Donnie: What about checking both FC and F77 ? if they differ, F77 is used. If F77 is empty, FC is used unless it's empty as well. dberkholz@gentoo.org 2004-10-01 15:30:07 0000 Yeah, I was thinking that but hadn't had time to comment. Also set both vars as well. kugelfang@gentoo.org 2004-10-10 06:16:20 0000 Okay guys. I just commited a new version of fortan.eclass. Donnie: Are you okay with the new F77/FC/F2C tests ? -- I compiled both dev-lang/R and app-sci/octave with this eclass. f77 had no problems like expected. f2c however made linking problems when used to compile octave due to missing MAIN__() function. The far reaching aim for this eclass should IMHO be to DEPEND on "virtual/fortran" . Comments on this ? dberkholz@gentoo.org 2004-10-10 12:13:55 0000 OK, here's a few questions, comments: You still don't need the two lines at the top of comment #5. Might want to declare PROFILE as a local, no need to say AVAILABLE="", if you initialize it, it's empty. Does ifc work on emt64? If so, we may need to add amd64 (bad name) to the list. What is this supposed to do? AVAILABLE="${AVAILABLE:1}" It just seems to chops off the first letter of the string, which later can result in fun things printed like: Installed are: 77 f2c i2c Looks like it would break things for anyone using g77, e.g. line 100. But apparently it doesn't somehow, since you said you tested it. Where's the $@ come from? I see you using it, but I don't see where it originates. Lines 59, 83. See the discussion on the lists on EXTRA_ECONF being only for users. You're making the assumption that every configure script with fortran uses --with-f77 rather than --with-fc, which is not the case. See sys-cluster/lam-mpi e.g. Might want PATCHES and PATCH to be local. It's a little confusing to be mixing f77 and g77, might want to use all g77. Other than that, looks good. I haven't tried it though. kugelfang@gentoo.org 2004-10-10 15:26:13 0000 a) the two lines... removed :-) b) that available="" is a left over, removed as well. c) it does: AVAILABLE="${AVAILABLE} tag", so there's always a space as the first character. AVAILABLE=${AVAILABLE:1} cuts it of. d) $@ expands to "$1$ "$2" ... "$n" e) i'd say, let's stay with "f77" name instead g77. Two reason: 1. i'm used to it :-D, 2. we'd have to rename ifc as well (ifc is called ifort since version 8.x i think) f) PATCH{ES} local now. g) EXTRA_ECONF: what about something like this: fortran.eclass: f2c_CONF="--with-f2c" f77_CONF="--with-f77" fortran_conf() { echo ${FORTRANC}_CONF } ebuild: f2c_CONF="foo" f77_CONF="bar" ... econf ... $(fortran_conf) h) Nope, there is still no em64t {icc, ifc} available. I already contacted Intel. dberkholz@gentoo.org 2004-10-10 15:48:03 0000 c) As discussed on IRC, be _very_ wary of this. Any changes to cause AVAILABLE to have a non-space in the first position will break the eclass. I'd suggest trying to find something more robust. supernova ~ # FOO=" foo bar" supernova ~ # echo $FOO foo bar It appears to be unnecessary anyway so could prolly be pulled. d) I know exactly what $@ does, I just have no clue what it's expanding. Args to need_fortran()? e) It's called ifort? Why do you call it if2 in the eclass then? g) You're missing a ${} in there. You might need to do some fun stuff like `eval echo ${${FORTRANC}_CONF}`. Prolly have a reasonable default in there too, so the ebuild doesn't have to specify if it meets the default. h) Nice work! Way to be on the ball. dberkholz@gentoo.org 2004-10-10 15:49:10 0000 c) Here's a more robust idea: ${FOO/[[:space:]]} dberkholz@gentoo.org 2004-10-10 15:50:20 0000 Actually that breaks if there isn't a space at the start also: ${FOO/^[[:space:]]} is better george@gentoo.org 2004-10-21 14:45:06 0000 Ok, so what's the status? Is the eclass ready to use? Also, what is the use, just add "inherit 64-bit fortran" and define supported compilers in FORTRAN var inside? Is there anythign else? BTW, I just tried to add fortran.eclass to blas-reference. It tested out Ok, but I would appreciate eclas creator taking a look at the package :). (This is -r1, keyworded -* for now). George kugelfang@gentoo.org 2005-01-17 05:55:53 0000 Folks, please see my mail to sci@g.o If you have still have complaints or wishes, please give them here. ribosome@gentoo.org 2005-10-30 17:32:37 0000 Packages that still need to be moved to the new eclass: dev-libs/blitz sci-biology/staden sci-chemistry/molden sci-libs/blas-reference sci-libs/lapack-atlas sci-libs/lapack-reference sci-libs/plplot sci-libs/scipy sci-mathematics/octave sci-mathematics/scilab sci-misc/camfr pbienst@gentoo.org 2005-10-31 01:14:35 0000 Blitz, scipy and camfr updated. ribosome@gentoo.org 2005-11-12 21:49:59 0000 Fixed: sci-biology/staden sci-libs/blas-reference sci-libs/lapack-atlas sci-libs/lapack-reference sci-mathematics/octave sci-mathematics/scilab Remaining: sci-chemistry/molden (spyderous) sci-libs/plplot (cryos) We also need to add a gfortran profile to fortran.eclass for gcc4. dberkholz@gentoo.org 2005-11-12 23:35:04 0000 (In reply to comment #18) > sci-chemistry/molden (spyderous) I'll get to this soon, but it's still not entirely clear to me how the eclass is meant to be used. Could someone point out examples for these cases? 1) any fortran compiler works, fortran is mandatory 2) only a couple of fortran compilers work, fortran is mandatory 3) any compiler works, fortran is optional When configure scripts accept environment values for F77 or FC, how are these supposed to get set in the ebuild? > We also need to add a gfortran profile to fortran.eclass for gcc4. Indeed; there's an mpich2 ebuild in progress that will require gfortran. So it would be nice to perhaps have a check like "if we're using gcc, then we need >=gcc-4 if gfortran is required or in use." ribosome@gentoo.org 2005-11-13 07:42:40 0000 Donnie: Start with "inherit fortran". This will redefine "pkg_setup" to test for the g77 Fortran compiler. If you know your package will also compile with f2c or ifc (the only other available profiles at this time), define something like FORTRAN="g77 f2c ifc" after inheriting the eclass. If you already define "src_unpack" in the ebuild, the test will not happen automatically, of course, so you need to call "need_fortran" inside "pkg_setup", with the valid profiles as arguments (for example: "need_fortran g77"). When Fortran support is optional, you can use the following inside "pkg_setup": if use fortran; then need_fortran g77 ifc f2g fi Unless I am mistaken, ebuilds should never set F77 or FC, but rather leave it to the user to specify the appropriate compiler. (This is what is done with CC/CXX.) "fortran.eclass" ensures an appropriate compiler is present, but will not choose the compiler for the user. (I think we rely on g77 being the default. If users want to change that, they likely know what they are doing.) dberkholz@gentoo.org 2005-11-13 14:24:04 0000 (In reply to comment #20) > Start with "inherit fortran". This will redefine "pkg_setup" to test for the > g77 Fortran compiler. If you know your package will also compile with f2c or > ifc (the only other available profiles at this time), define something like > FORTRAN="g77 f2c ifc" after inheriting the eclass. If you already define > "src_unpack" in the ebuild, the test will not happen automatically, of course, > so you need to call "need_fortran" inside "pkg_setup", with the valid profiles > as arguments (for example: "need_fortran g77"). Why just call need_fortran instead of calling fortran-pkg_setup within pkg_setup()? That would ensure that any later changes also get integrated. > Unless I am mistaken, ebuilds should never set F77 or FC, but rather leave it > to the user to specify the appropriate compiler. (This is what is done with > CC/CXX.) "fortran.eclass" ensures an appropriate compiler is present, but will > not choose the compiler for the user. (I think we rely on g77 being the > default. If users want to change that, they likely know what they are doing.) OK. I see sci-misc/xfoil doing weird things with FC=$FORTRANC and sci-libs/blas-reference setting FC manually. ribosome@gentoo.org 2005-11-13 16:37:23 0000 (In reply to comment #21) (I meant pkg_setup when I said src_unpack in comment #20.) > Why just call need_fortran instead of calling fortran-pkg_setup within > pkg_setup()? That would ensure that any later changes also get integrated. Yes, that would be even better, I think. Once all packages are moved to the new system, I will review all ebuilds inheriting fortran.eclass and change that. ribosome@gentoo.org 2005-11-28 18:36:03 0000 Created an attachment (id=73772) molden-4.3-fortran.patch spyderous: Suggested patch for molden-4.3. Would you be Ok with my committing it? ribosome@gentoo.org 2005-11-28 18:56:26 0000 Created an attachment (id=73774) plplot-5.5.2-fortran.patch cryos: Suggested patch for plplot. Would you be Ok with my committing it? dberkholz@gentoo.org 2005-11-28 20:00:19 0000 (In reply to comment #23) > Created an attachment (id=73772) [edit] > molden-4.3-fortran.patch > > spyderous: > > Suggested patch for molden-4.3. Would you be Ok with my committing it? This section of the ebuild is still weird: # Set fortran compiler, since gcc-config doesn't [ -z ${FC} ] && FC="g77" Should probably get fixed to pass the correct FC in the make call instead. BTW, how's tc-getF77() from toolchain-funcs.eclass relate to all the fortran.eclass stuff? dberkholz@gentoo.org 2005-12-05 18:14:42 0000 Dunno if any of you happen to use nano, but I created some syntax highlighting rules for the eclass to make things easier for me. The first part checks the FORTRAN variable at the top for valid values, and the second part checks for uses of FORTRANC or fortran CFLAGS/compilers later on. syntax "ebuild" "\.e(build|class)$" # Fortran -- needs to be before = color magenta "FORTRAN=\"(g77|ifc|f2c) ?(g77|ifc|f2c)? ?(g77|ifc|f2c)?\"" # Fix quotes from FORTRAN color white "\"" ... C(XX)?FLAGS stuff ... # More fortran color red "\<FORTRAN(C)?\>" "\<FFLAGS\>" "\<F(C|77|90)\>" ribosome@gentoo.org 2005-12-08 13:07:19 0000 > This section of the ebuild is still weird: > # Set fortran compiler, since gcc-config doesn't > [ -z ${FC} ] && FC="g77" Yes, this should probably be simply FC="$(tc-getF77)". > BTW, how's tc-getF77() from toolchain-funcs.eclass relate to all the > fortran.eclass stuff? I think they are separate things. The fortran eclass just works around a Portage limitation to enforce dependency on a Fortran compiler. The user is still free to choose the compiler he likes and is responsible for setting F77 in "make.conf" to something that is installed on his system. The only place where the two systems could cross, I think, is that the fortran eclass could check the value of F77 and die with an error if the selected compiler does not work with the package. (Maybe the fortran eclass could also be extended to die if the selected compiler is not installed but that is taking the user by the hand quite a bit.) Another thing I would like to see is the possibility to ignore the compiler check to allow users to try any compiler they wish and, eventually, tell us if they were successful. (Something like "IGNORE_FORTRAN_CHECK='1' F77='icc' emerge plplot".) That TODO list is growing... :) dberkholz@gentoo.org 2005-12-08 13:19:03 0000 (In reply to comment #27) > Yes, this should probably be simply FC="$(tc-getF77)". I think using tc-getF77 may not be the best idea because FORTRAN may not include g77, which is the default of tc-getF77. I've been using FC="${FORTRANC}", which relies on fortran.eclass for its value. So in an admittedly weird scenario, F77 is not set and the package will not compile with g77 so FORTRAN="ifc f2c", for example. Then fortran.eclass thinks we're using ifc, but tc-getF77 thinks we're using g77. This could cause annoying issues. > I think they are separate things. The fortran eclass just works around a > Portage limitation to enforce dependency on a Fortran compiler. The user is > still free to choose the compiler he likes and is responsible for setting F77 > in "make.conf" to something that is installed on his system. The only place > where the two systems could cross, I think, is that the fortran eclass could > check the value of F77 and die with an error if the selected compiler does > not work with the package. (Maybe the fortran eclass could also be extended to > die if the selected compiler is not installed but that is taking the user by > the hand quite a bit.) Isn't that already the case if the selected compiler isn't in FORTRAN? > Another thing I would like to see is the possibility to > ignore the compiler check to allow users to try any compiler they wish > and, eventually, tell us if they were successful. (Something like > "IGNORE_FORTRAN_CHECK='1' F77='icc' emerge plplot".) Probably would be useful if they could just ignore the FORTRAN setting in the ebuild and run FORTRAN="their compiler" emerge foo. marten@xtal.rwth-aachen.de 2005-12-23 06:14:07 0000 I'd like to have a way to select the FC inside of an ebuild. For example an application can be compiled with ifc and g95, but needs different cmd line flags. Then I would like to set the compiler to use based on a useflag (ifc). Currently the eclass just checks for the default FC and if it is not in the scope of allowed FCs for this ebuild it dies. So it should be possible to either deactivate this check from inside the ebuild, if the ebuild will handle the invocation of the correct FC. cryos@gentoo.org 2005-12-23 06:39:30 0000 I would like to see a gfortran profile added - any objections to that going in? I would also like to see similar behaviour to that before the eclass where the best fortran compiler was chosen rather than failing. I think that it should default to g77, and gfortran if g77 is not present. If the ifc use flag is specified and the ebuild accepts it then that should be the default (if that makes sense). Kugelfang and I talked about this on IRC but I thought may be some of it should be written down while I remember :) It does seem that some of our packages are regressing in their behaviour after the moves to the new eclass. So we should document this behaviour for our users somewhere, or fix the eclass to be more automated (I prefer more automation). What do others think? dberkholz@gentoo.org 2005-12-23 08:46:30 0000 (In reply to comment #30) > I would like to see a gfortran profile added - any objections to that going in? > I would also like to see similar behaviour to that before the eclass where the > best fortran compiler was chosen rather than failing. I think that it should > default to g77, and gfortran if g77 is not present. If the ifc use flag is > specified and the ebuild accepts it then that should be the default (if that > makes sense). I still don't understand why you want to default to g77 first, then gfortran. On any system with gfortran that's obviously what people will want to use before g77. We need to get rid of the ifc USE flag, it's an abomination. ifc should be controlled through the F(C|77|90) variables. jan.simons@web.de 2005-12-23 16:46:43 0000 > We need to get rid of the ifc USE flag, it's an abomination. ifc should be controlled through the F(C|77|90) variables. I herbly object this, as it is possible to set useflags for individual ebuilds and this is not possible with the environment-variables. So if you just want to have some programmes built with ifc, then it would become a real pita to upgrade the system. dberkholz@gentoo.org 2005-12-23 17:02:38 0000 (In reply to comment #32) > > We need to get rid of the ifc USE flag, it's an abomination. ifc should be > controlled through the F(C|77|90) variables. > > I herbly object this, as it is possible to set useflags for individual ebuilds > and this is not possible with the environment-variables. So if you just want to > have some programmes built with ifc, then it would become a real pita to > upgrade the system. Then another way needs to be found. This way is wrong. ribosome@gentoo.org 2005-12-24 11:32:43 0000 (In reply to comment #33) > > Then another way needs to be found. This way is wrong. > Not only wrong: it does not work. Enabling "icc" does not set the CC environment variable, so you currently need to do both: set the environment variable *and* the USE flag. USE flags are for optional features in a package, not for compiler selection. If you need package specific environment variables, bug the Portage team, and use some bashrc tricks in the meantime. nbigaouette@gmail.com 2006-01-13 14:28:36 0000 Hey guys, thanx for working on fortran code for gentoo. I'm using ifort (intel's fortran compiler, was called ifc before) and now PGI's set of compilers. The eclass doesn't seems to support something else than fortran 77 with g77 and f2c. ifc is now called ifort and supports fortran 90/95 (even some 2003). What should be done to make possible the use of pgi's? Is it only a something like modifying fortran.eclass? Or the profiles in it are stored somewhere else? Thanx ribosome@gentoo.org 2006-01-13 15:27:37 0000 (In reply to comment #35) > Is it only a something like modifying fortran.eclass? Or the profiles in it are > stored somewhere else? Everything is the eclass. (And we do need more profiles...) cryos@gentoo.org 2006-01-14 17:26:17 0000 Created an attachment (id=77137) fortran.eclass.diff - proposed change to eclass Here is a proposed change to the fortran eclass. This relates to bug 108781 and other ebuilds where previous behaviour has changed. Ebuilds using fortran have become less easily useable due to the automatic selection of an appropriate compiler being taken away. Using this patched eclass gfortran was automatically selected on my gcc4.0 system, whilst g77 was automatically selected on my gcc3.4 system. This approach can be extended by adding in more elifs defining a default priority order when the user has not selected a fortran compiler previously. Any objections to me adding this patch to the tree? markusle@gentoo.org 2006-01-15 07:50:27 0000 (In reply to comment #37) > Created an attachment (id=77137) [edit] > > Any objections to me adding this patch to the tree? > Hi Marcus, The patch looks fine to me, even though I haven't been able to try it out since my system is still lacking gcc-4.0.x. The only thing that came to mind would be to make the error messages (lines 88 and 91 in the patched ebuild) somewhat more precise, i.e. "eerror.... emerge sys-devel/gcc-4.*" "eerror.....emerge sys-devel/gcc-3.*" or sth along these lines. Thanks, Markus ribosome@gentoo.org 2006-01-15 12:05:56 0000 I think it would be better if we could simply retrieve the selected/default Fortran compiler from tc-getF77 in the toolchain-funcs eclass. So perhaps the fix to default to gfortran if gcc 4 is installed could be put in that eclass instead? Maybe getF77 is not an appropriate name now that gcc 4 supports fortran 77/90/95 (I think), so a new function would be better? Also, we should probably add something to the make.conf man page to explain that MY_FORTRAN can be used to select a fortran compiler. (And while on the topic, why not simply FORTRAN, FORTRANC or FC? Why MY_FORTRAN?) dberkholz@gentoo.org 2006-01-15 15:22:17 0000 (In reply to comment #39) > I think it would be better if we could simply retrieve the selected/default > Fortran compiler from tc-getF77 in the toolchain-funcs eclass. So perhaps the > fix to default to gfortran if gcc 4 is installed could be put in that eclass > instead? Maybe getF77 is not an appropriate name now that gcc 4 supports > fortran 77/90/95 (I think), so a new function would be better? Changes definitely shouldn't be made to toolchain-funcs without passing through the maintainers. > Also, we should probably add something to the make.conf man page to explain > that MY_FORTRAN can be used to select a fortran compiler. (And while on the > topic, why not simply FORTRAN, FORTRANC or FC? Why MY_FORTRAN?) You can set FC. if [ -n "${F77}" -o -n "${FC}" -o -n "${F2C}" ]; then if [ -n "${F77}" ]; then FC="${F77}" # F77 overwrites FC fi if [ -n "${FC}" -a -n "${F2C}" ]; then ewarn "Using ${FC} and f2c is impossible. Disabling F2C !" F2C="" # Disabling f2c MY_FORTRAN="$(basename ${FC})" # set MY_FORTRAN to filename of # the Fortran Compiler cryos@gentoo.org 2006-01-15 16:30:42 0000 Markus: I had thought of doing that originally, but was not certain. I have added it in now as I believe the verbosity can only help. Olivier: I see where you are coming from, but the move to the eclass has removed functionality that was already present in the ebuilds before the move. I think this patch is a good solution right now, but may be in the longer term we talk to toolchain about this. I had a look and it does not look like they have really taken the fortran changes into account yet. I have committed a slightly updated version of the patch I proposed. Please take a look. I tested it here with my GCC 3.4 and my GCC 4.0 systems with no side effects. This seems the sanest way to improve default behaviour for now, but could probably be further improved. I like Donnie's idea of a default selection order of the available compilers, may be allowing users to set their preferred order too. GCC 4.0 will be entering the testing branch very soon though, and so I felt it was necessary to get a reasonable solution into the tree sooner rather than later. I still welcome any feedback on this or any other changes I have made. dberkholz@gentoo.org 2006-01-16 23:51:45 0000 I just fixed the gfortran patch. It missed a part about setting FORTRANC. I'm playing with blas-atlas and lapack-atlas with gfortran now -- got blas-atlas working fine, still screwing around with lapack. Can't find any bugs about either yet. dberkholz@gentoo.org 2006-01-17 00:23:36 0000 (In reply to comment #42) > I'm playing with blas-atlas and lapack-atlas with gfortran now -- got > blas-atlas working fine, still screwing around with lapack. Can't find any bugs > about either yet. Just got lapack-atlas working. A call to gcc-major-version() was getting screwed up because of an earlier setting of CC to an invalid CC value for hacking around the build system. dberkholz@gentoo.org 2006-06-21 08:32:08 0000 Something's a bit screwed up with our handling of the F77 and FC variables, but it hasn't hit us yet. FC should be for Fortran90 code, F77 for Fortran77 code. They shouldn't be overwriting each other and should get set up independently for use in ebuilds. Also this could use an enhancement to allow passing in arbitrary Fortran compilers that aren't yet in the allowed compilers list for that ebuild. nbigaouette@gmail.com 2006-09-08 13:54:19 0000 Created an attachment (id=96435) Adding of PGI compilers (pgf90 & pgf77) (In reply to comment #44) > Something's a bit screwed up with our handling of the F77 and FC variables, but > it hasn't hit us yet. FC should be for Fortran90 code, F77 for Fortran77 code. > They shouldn't be overwriting each other and should get set up independently > for use in ebuilds. > > Also this could use an enhancement to allow passing in arbitrary Fortran > compilers that aren't yet in the allowed compilers list for that ebuild. > I tryed to emerge gentoo-science's openmpi using Portland Group's set of compiler (PGI's pgf90 and pgf77). I did: CC="pgcc" CXX="pgCC" F77="pgf77" FC="pgf90" emerge -av sys-cluster/openmpi but the fortran.eclass doesn't support those compilers. I added them with the patch above. I also encontered problems with F77 overwriting FC. The patch contain a workwaround for PGI compilers. dberkholz@gentoo.org 2006-09-08 14:22:35 0000 (In reply to comment #45) > > Also this could use an enhancement to allow passing in arbitrary Fortran > > compilers that aren't yet in the allowed compilers list for that ebuild. > > > I tryed to emerge gentoo-science's openmpi using Portland Group's set of > compiler (PGI's pgf90 and pgf77). I did: > CC="pgcc" CXX="pgCC" F77="pgf77" FC="pgf90" emerge -av sys-cluster/openmpi > but the fortran.eclass doesn't support those compilers. I added them with the > patch above. Yeah this needs to get fixed properly with a compiler override to use "unsupported" compilers. > I also encontered problems with F77 overwriting FC. The patch contain a > workwaround for PGI compilers. This was just done incorrectly in the first place. FC should be used for Fortran 90/95 and F77 for Fortran 77. Probably just having a $FORTRANC variable to use is also incorrect. timcera@earthlink.net 2006-09-27 15:27:48 0000 I am confused about how to use the fortran.eclass. Do I use $MY_FORTRAN? $FC? $F77? Could some guidance be added to the man page? What would be really helpful is if all of the environment variables FC/FCFLAGS/FCLIBS OR F77/FFLAGS/FLIBS be set accordingly to the following standards used by autoconf: http://www.gnu.org/software/autoconf/manual/html_node/Fortran-Compiler.html Another helpful feature would be for the 'debug' USE variable to set the FCFLAGS or FFLAGS variable appropriately for the compiler selected (for example: FCFLAGS='-g' for FC='gfortran' if debug set, otherwise FCFLAGS='-O2') Thanks, Tim P.S. Shouldn't the 'Component' for the bug be 'Eclasses and Profiles'? dberkholz@gentoo.org 2006-09-27 16:00:52 0000 How to use: 1) inherit fortran 2) Set FORTRAN="gfortran ifc" for list of working compilers 3) If you set your own pkg_setup(), run fortran_pkg_setup() in it 4) Use the $FORTRANC variable to force the Fortran compiler in whatever way needed if the package doesn't respect a user's FC/F77 setting. 4) is the really bad part, we need to split FORTRANC up properly for F77 and F90/95/03 using F77 and FC variables. A patch to do this would be useful. 40807 2004-09-30 14:07 0000 fortran-check.eclass fortran-check.eclass text/plain IyBDb3B5cmlnaHQgMTk5OS0yMDA0IEdlbnRvbyBGb3VuZGF0aW9uCiMgRGlzdHJpYnV0ZWQgdW5k ZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSB2MgojICRIZWFk ZXI6ICQKCkVDTEFTUz1mb3J0cmFuLWNoZWNrCklOSEVSSVRFRD0iJElOSEVSSVRFRCAkRUNMQVNT IgoKZm9ydHJhbi1jaGVja19wa2dfc2V0dXAoKSB7CgkjIENoZWNrIGZvciBhIEZvcnRyYW4gY29t cGlsZXIuCglpZiAhIHdoaWNoICR7Rjc3Oi1nNzd9ICY+IC9kZXYvbnVsbDsgdGhlbgoJCWVjaG8K CQllZXJyb3IgIlRoZSBGb3J0cmFuIGNvbXBpbGVyIFwiJHtGNzc6LWc3N31cIiBjb3VsZCBub3Qg YmUgZm91bmQgb24geW91ciBzeXN0ZW0uIgoJCWlmIFsgLXogJHtGNzd9IF0gfHwgWyAke0Y3N30g PSBnNzcgXTsgdGhlbgoJCQllZXJyb3IgJ1BsZWFzZSByZWluc3RhbGwgInN5cy1kZXZlbC9nY2Mi IHdpdGggdGhlICJmNzciICJVU0UiIGZsYWcgZW5hYmxlZC4nCgkJZWxzZQoJCQllZXJyb3IgJ1Bs ZWFzZSBtYWtlIHN1cmUgdGhlIHZhcmlhYmxlICR7Rjc3fSBpcyBzZXQgdG8gdGhlIG5hbWUgb2Yg YSB2YWxpZCcKCQkJZWVycm9yICdGb3J0cmFuIGNvbXBpbGVyIGluc3RhbGxlZCBvbiB5b3VyIHN5 c3RlbS4gTWFrZSBzdXJlIHRoaXMgZXhlY3V0YWJsZScKCQkJZWVycm9yICdpcyBpbiBhIGRpcmVj dG9yeSBpbmNsdWRlZCBpbiAiUEFUSCIsIGFuZCB0aGF0IHRoZSBjb3JyZXNwb25kaW5nJwoJCQll ZXJyb3IgJyJVU0UiIGZsYWcgaXMgc2V0IGlmIGFwcGxpY2FibGUgKGZvciBleGFtcGxlICJpZmMi IGlmIHlvdSB1c2UgdGhlJwoJCQllZXJyb3IgJ0ludGVsIEZvcnRyYW4gQ29tcGlsZXIpLicKCQlm aQoJCWRpZSAiRm9ydHJhbiBjb21waWxlciBub3QgZm91bmQuIgoJZmkKfQoKRVhQT1JUX0ZVTkNU SU9OUyBwa2dfc2V0dXAK 40812 2004-09-30 15:06 0000 New fortran.eclass - Kugelfang's propsal fortran.eclass text/plain IyBDb3B5cmlnaHQgMTk5OS0yMDA0IEdlbnRvbyBGb3VuZGF0aW9uCiMgRGlzdHJpYnV0ZWQgdW5k ZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSB2MgojICRIZWFk ZXIkCiMKIyBBdXRob3I6IERhbm55IHZhbiBEeWsgPGF6YXJhaEBnZW50b28ub3JnPgojCgpFQ0xB U1M9Zm9ydHJhbgpJTkhFUklURUQ9IiRJTkhFUklURUQgJEVDTEFTUyIKCkRFU0NSSVBUSU9OPSJC YXNlZCBvbiB0aGUgJHtFQ0xBU1N9IGVjbGFzcyIKCiMgbmVlZF9mb3J0cmFuIDxwcm9maWxlcz4K IwojICBwcm9maWxlcyA9IDxwcm9maWxlPiAuLi4gPHByb2ZpbGU+CiMgIHByb2ZpbGUgPSA8Y29t cGlsZXI+LTx2ZXJzaW9uPgojCiMgIGNvbXBpbGVyOgojICAgICogZjc3IC0gR0NDIEZvcnRyYW4g NzcKIyAgICAqIGYyYyAtIEZvcnRyYW4gMiBDIFRyYW5zbGF0b3IKIyAgICAqIGlmYyAtIEludGVs IEZvcnRyYW4gQ29tcGlsZXIKbmVlZF9mb3J0cmFuKCkgewoJaWYgWyAteiAiJEAiIF07IHRoZW4K CQllZXJyb3IgIkNhbGwgbmVlZF9mb3J0cmFuIHdpdGggYXQgbGVhc3Qgb25lIGFyZ3VtZW50ICEi CglmaSAKCUZPUlRBTj0iIgoJZm9yIFBST0ZJTEUgaW4gJEA7IGRvCgkJY2FzZSAke1BST0ZJTEV9 IGluCgkJCWY3NykKCQkJCWlmIFsgLXggIiQod2hpY2ggZzc3IDI+IC9kZXYvbnVsbCkiIF07IHRo ZW4KCQkJCQlGT1JUUkFOPSIke0ZPUlRSQU59IGY3NyIKCQkJCWZpCgkJCQk7OwoJCQlmMmMpCgkJ CQlpZiBbIC14ICIkKHdoaWNoIGYyYyAyPiAvZGV2L251bGwpIiBdOyB0aGVuCgkJCQkJRk9SVFJB Tj0iJHtGT1JUUkFOfSBmMmMiCgkJCQlmaQoJCQkJOzsKCQkJaWZjKQoJCQkJY2FzZSAke0FSQ0h9 IGluCgkJCQkJeDg2fGlhNjQpCgkJCQkJCWlmIFsgLXggIiQod2hpY2ggaWYyIDI+IC9kZXYvbnVs bCkiIF07IHRoZW4KCQkJCQkJCUZPUlRSQU49IiR7Rk9SVFJBTn0gaWZjIgoJCQkJCQlmaQoJCQkJ CQk7OwoJCQkJCSopCgkJCQkJCTs7CgkJCQllc2FjCgkJCQk7OwoJCWVzYWMKCWRvbmUKCWlmIFsg LXogIiR7Rk9SVFJBTn0iIF07IHRoZW4KCQllZXJyb3IgIk5vbmUgb2YgdGhlIG5lZWRlZCBGb3J0 cmFuIENvbXBpbGVycyAoJEApIGlzIGluc3RhbGxlZC4iCgkJZWVycm9yICJUbyBpbnN0YWxsIG9u ZSBvZiB0aGVzZSwgY2hvb3NlIG9uZSBvZiB0aGUgZm9sbG93aW5nIHN0ZXBzOiIKCQlpPTEKCQlm b3IgUFJPRklMRSBpbiAkQDsgZG8KCQkJY2FzZSAke1BST0ZJTEV9IGluCgkJCQlmNzcpCgkJCQkJ ZWVycm9yICJbJHtpfV0gVVNFPVwiZjc3XCIgZW1lcmdlIHN5cy1kZXZlbC9nY2MiCgkJCQkJOzsK CQkJCWYyYykKCQkJCQllZXJyb3IgIlske2l9XSBlbWVyZ2UgZGV2LWxhbmcvZjJjIgoJCQkJCTs7 CgkJCQlpZmMpCgkJCQkJY2FzZSAke0FSQ0h9IGluCgkJCQkJCXg4NnxpYTY0KQoJCQkJCQkJZWVy cm9yICJbJHtpfV0gZW1lcmdlIGRldi1sYW5nL2lmYyIKCQkJCQkJCTs7CgkJCQkJCSopCgkJCQkJ CQk7OwoJCQkJCWVzYWMKCQkJZXNhYwoJCQlpPSQoKGkgKyAxKSkKCQlkb25lCgkJZGllICJJbnN0 YWxsIGEgRm9ydHJhbiBDb21waWxlciAhIgoJZWxzZQoJCWVpbmZvICJZb3UgbmVlZCBvbmUgb2Yg dGhlc2UgRm9ydHJhbiBDb21waWxlcnM6ICRAIgoJCWVpbmZvICJJbnN0YWxsZWQgYXJlOiR7Rk9S VFJBTn0iCglmaQoJCn0K 73772 2005-11-28 18:36 0000 molden-4.3-fortran.patch molden-4.3-fortran.patch text/plain LS0tIG1vbGRlbi00LjMuZWJ1aWxkCTIwMDUtMTEtMjggMTc6MTc6MDEuMDAwMDAwMDAwIC0wNTAw CisrKyBtb2xkZW4tNC4zLXIxLmVidWlsZAkyMDA1LTExLTI4IDE3OjIwOjUyLjAwMDAwMDAwMCAt MDUwMApAQCAtMiw3ICsyLDcgQEAKICMgRGlzdHJpYnV0ZWQgdW5kZXIgdGhlIHRlcm1zIG9mIHRo ZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSB2MgogIyAkSGVhZGVyOiAvdmFyL2N2c3Jvb3Qv Z2VudG9vLXg4Ni9zY2ktY2hlbWlzdHJ5L21vbGRlbi9tb2xkZW4tNC4zLmVidWlsZCx2IDEuNCAy MDA1LzA1LzE0IDA4OjU1OjI2IGtsb2VyaSBFeHAgJAogCi1pbmhlcml0IGV1dGlscyB0b29sY2hh aW4tZnVuY3MgZmxhZy1vLW1hdGljCitpbmhlcml0IGV1dGlscyB0b29sY2hhaW4tZnVuY3MgZmxh Zy1vLW1hdGljIGZvcnRyYW4KIAogTVlfUD0iJHtQTn0ke1BWfSIKIERFU0NSSVBUSU9OPSJEaXNw bGF5IG1vbGVjdWxhciBkZW5zaXR5IGZyb20gR0FNRVNTLVVLLCBHQU1FU1MtVVMsIEdBVVNTSUFO IGFuZCBNb3BhYy9BbXBhYy4iCkBAIC0yNSwxMyArMjUsNiBAQAogCSMgU2V0IGZvcnRyYW4gY29t cGlsZXIsIHNpbmNlIGdjYy1jb25maWcgZG9lc24ndAogCVsgLXogJHtGQ30gXSAmJiBGQz0iZzc3 IgogCi0JIyBDaGVjayBmb3IgZm9ydHJhbiBjb21waWxlcgotCWlmIFsgISAiYHdoaWNoICR7RkN9 IDI+IC9kZXYvbnVsbGAiIF07IHRoZW4KLQkJZWVycm9yICJGb3J0cmFuIGNvbXBpbGVyIG5vdCBm b3VuZC4iCi0JCWVlcnJvciAiUGxlYXNlIHJlY29tcGlsZSBzeXMtZGV2ZWwvZ2NjIHdpdGggZm9y dHJhbiBpbiBVU0UgZmxhZ3MuIgotCQlkaWUKLQlmaQotCiAJdW5wYWNrICR7QX0KIAljZCAke1N9 CiAK 73774 2005-11-28 18:56 0000 plplot-5.5.2-fortran.patch plplot-5.5.2-fortran.patch text/plain LS0tIHBscGxvdC01LjUuMi5lYnVpbGQJMjAwNS0xMS0yOCAxNzoxNzo0Ni4wMDAwMDAwMDAgLTA1 MDAKKysrIHBscGxvdC01LjUuMi1yMS5lYnVpbGQJMjAwNS0xMS0yOCAyMTo1NDoxNS4wMDAwMDAw MDAgLTA1MDAKQEAgLTIsNyArMiw3IEBACiAjIERpc3RyaWJ1dGVkIHVuZGVyIHRoZSB0ZXJtcyBv ZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgdjIKICMgJEhlYWRlcjogL3Zhci9jdnNy b290L2dlbnRvby14ODYvc2NpLWxpYnMvcGxwbG90L3BscGxvdC01LjUuMi5lYnVpbGQsdiAxLjMg MjAwNS8wOC8yMCAyMDowNjo0NiBjcnlvcyBFeHAgJAogCi1pbmhlcml0IGV1dGlscworaW5oZXJp dCBldXRpbHMgZm9ydHJhbgogCiAjIEtub3duIHByb2JsZW1zIHdpdGggdGhpcyBlYnVpbGQ6CiAj IC0gTm8gc3VwcG9ydCBmb3IgbGlicWh1bGwuCkBAIC00MSwxNCArNDEsMTIgQEAKIAkjIE9wdGlv bmFsIHN1cHBvcnQgZm9yIGxpYnFodWxsIChjdXJyZW50bHkgZG9lc24ndCB3b3JrKS4KIAkjIHFo dWxsPyAoIG1lZGlhLWxpYnMvcWh1bGwgKQogCitGT1JUUkFOPSJnNzcgaWZjIgorCiBwa2dfc2V0 dXAoKSB7Ci0JIyBJZiB0aGUgZm9ydHJhbiBpbnRlcmZhY2UgaXMgd2FudGVkLCB0aGUgZ251IGY3 NyBjb21waWxlcgotCSMgaXMgbmVlZGVkIHVubGVzcyBpZmMgaXMgdXNlZCAod2hpY2ggaXMgdGFr ZW4gY2FyZSBvZiBpbgotCSMgdGhlIGRlcGVuZGVuY2llcykuCi0JdXNlIGZvcnRyYW4gJiYgISB1 c2UgaWZjIHx8IGlmIFsgLXogJ3doaWNoIGc3NycgXTsgdGhlbgotCQllZXJyb3IgIkdOVSBmb3J0 cmFuIDc3IGNvbXBpbGVyIG5vdCBmb3VuZCBvbiB0aGUgc3lzdGVtLiIKLQkJZWVycm9yICJQbGVh c2UgYWRkIGZvcnRyYW4gdG8geW91ciBVU0UgZmxhZ3MgYW5kIHJlZW1lcmdlIGdjYy4iCi0JCWRp ZQorCSMgSWYgdGhlIGZvcnRyYW4gaW50ZXJmYWNlIGlzIHdhbnRlZCwgd2UgbmVlZCBhIEZvcnRy YW4gY29tcGlsZXIuCisJaWYgdXNlIGZvcnRyYW47IHRoZW4KKwkJZm9ydHJhbl9wa2dfc2V0dXAK IAlmaQogfQogCg== 77137 2006-01-14 17:26 0000 fortran.eclass.diff - proposed change to eclass fortran.eclass.diff text/plain LS0tIGVjbGFzcy9mb3J0cmFuLmVjbGFzcy5vcmlnCTIwMDUtMTEtMjUgMDE6NTY6NDguMDAwMDAw MDAwICswMDAwCisrKyBlY2xhc3MvZm9ydHJhbi5lY2xhc3MJMjAwNi0wMS0xNSAwMToxOToxMC4w MDAwMDAwMDAgKzAwMDAKQEAgLTMyLDYgKzMyLDcgQEAKICMgIHByb2ZpbGVzID0gPHByb2ZpbGU+ IC4uLiA8cHJvZmlsZT4KICMKICMgIHByb2ZpbGU6CisjICAgKiBnZm9ydHJhbiAtIEdDQyBGb3J0 cmFuIDk1CiAjICAgKiBnNzcgLSBHQ0MgRm9ydHJhbiA3NwogIyAgICogZjJjIC0gRm9ydHJhbiAy IEMgVHJhbnNsYXRvcgogIyAgICogaWZjIC0gSW50ZWwgRm9ydHJhbiBDb21waWxlcgpAQCAtNDcs NiArNDgsMTEgQEAKIAlsb2NhbCBQUk9GSUxFCiAJZm9yIFBST0ZJTEUgaW4gJEA7IGRvCiAJCWNh c2UgJHtQUk9GSUxFfSBpbgorCQkJZ2ZvcnRyYW4pCisJCQkJaWYgWyAteCAiJCh3aGljaCBnZm9y dHJhbiAyPiAvZGV2L251bGwpIiBdOyB0aGVuCisJCQkJCUFWQUlMQUJMRT0iJHtBVkFJTEFCTEV9 IGdmb3J0cmFuIgorCQkJCWZpCisJCQkJOzsKIAkJCWc3NykKIAkJCQlpZiBbIC14ICIkKHdoaWNo IGc3NyAyPiAvZGV2L251bGwpIiBdOyB0aGVuCiAJCQkJCUFWQUlMQUJMRT0iJHtBVkFJTEFCTEV9 IGc3NyIKQEAgLTc4LDYgKzg0LDkgQEAKIAkJaT0xCiAJCWZvciBQUk9GSUxFIGluICRAOyBkbwog CQkJY2FzZSAke1BST0ZJTEV9IGluCisJCQkJZ2ZvcnRyYW4pCisJCQkJCWVlcnJvciAiWyR7aX1d IFVTRT1cImZvcnRyYW5cIiBlbWVyZ2Ugc3lzLWRldmVsL2djYyIKKwkJCQkJOzsKIAkJCQlnNzcp CiAJCQkJCWVlcnJvciAiWyR7aX1dIFVTRT1cImZvcnRyYW5cIiBlbWVyZ2Ugc3lzLWRldmVsL2dj YyIKIAkJCQkJOzsKQEAgLTExNyw5ICsxMjYsMTMgQEAKIAkJCWZpCiAJCWZpCiAKLQkJIyBkZWZh dWx0IHRvIGc3NworCQkjIGRlZmF1bHQgdG8gZ2ZvcnRyYW4gaWYgYXZhaWxhYmxlLCBnNzcgaWYg bm90CiAJCXVzZSBkZWJ1ZyAmJiBlY2hvICJNWV9GT1JUUkFOOiBcIiR7TVlfRk9SVFJBTn1cIiIK LQkJTVlfRk9SVFJBTj0ke01ZX0ZPUlRSQU46PWc3N30KKwkJaWYgaGFzcSBnZm9ydHJhbiAke0FW QUlMQUJMRX07IHRoZW4KKwkJCU1ZX0ZPUlRSQU49JHtNWV9GT1JUUkFOOj1nZm9ydHJhbn0KKwkJ ZWxzZQorCQkJTVlfRk9SVFJBTj0ke01ZX0ZPUlRSQU46PWc3N30KKwkJZmkKIAkJdXNlIGRlYnVn ICYmIGVjaG8gIk1ZX0ZPUlRSQU46IFwiJHtNWV9GT1JUUkFOfVwiIgogCiAJCWlmICEgaGFzcSAk e01ZX0ZPUlRSQU59ICR7QVZBSUxBQkxFfTsgdGhlbgo= 96435 2006-09-08 13:54 0000 Adding of PGI compilers (pgf90 & pgf77) fortran.eclass.patch text/plain LS0tIGZvcnRyYW5fb3JpZy5lY2xhc3MJMjAwNi0wOS0wOCAxNTo1MDoyOC4wMDAwMDAwMDAgLTA0 MDAKKysrIGZvcnRyYW4uZWNsYXNzCTIwMDYtMDktMDggMTY6MzY6MjMuMDAwMDAwMDAwIC0wNDAw CkBAIC0zNiw2ICszNiw4IEBACiAjICAgKiBnNzcgLSBHQ0MgRm9ydHJhbiA3NwogIyAgICogZjJj IC0gRm9ydHJhbiAyIEMgVHJhbnNsYXRvcgogIyAgICogaWZjIC0gSW50ZWwgRm9ydHJhbiBDb21w aWxlcgorIyAgICogcGdmNzcgLSBQb3J0bGFuZCBHcm91cCBGb3J0cmFuIDc3IGNvbXBpbGVyCisj ICAgKiBwZ2Y5MCAtIFBvcnRsYW5kIEdyb3VwIEZvcnRyYW4gOTAvOTUgY29tcGlsZXIKICMKICMg Q2hlY2tzIGlmIGF0IGxlYXN0IG9uZSBvZiA8cHJvZmlsZXM+IGlzIGluc3RhbGxlZC4KICMgQ2hl Y2tzIGFsc28gaWYgRjc3ICh0aGUgZm9ydHJhbiBjb21waWxlciB0byB1c2UpIGlzIGF2YWlsYWJs ZQpAQCAtNjMsNiArNjUsMTggQEAKIAkJCQkJQVZBSUxBQkxFPSIke0FWQUlMQUJMRX0gZjJjIgog CQkJCWZpCiAJCQkJOzsKKwkJCXBnZjc3KQorCQkJCWlmIFsgLXggIiQod2hpY2ggcGdmNzcgMj4g L2Rldi9udWxsKSIgXTsgdGhlbgorCQkJCQlBVkFJTEFCTEU9IiR7QVZBSUxBQkxFfSBwZ2Y3NyIK KwkJCQlmaQorCQkJCTs7CisJCQlwZ2Y5MCkKKwkJCQlpZiBbIC14ICIkKHdoaWNoIHBnZjkwIDI+ IC9kZXYvbnVsbCkiIF07IHRoZW4KKwkJCQkJQVZBSUxBQkxFPSIke0FWQUlMQUJMRX0gcGdmOTAi CisgICAgICAgICAgICAgICAgZWxzZQorICAgICAgICAgICAgICAgICAgICBlY2hvICJFbHNlLi4u IgorCQkJCWZpCisJCQkJOzsKIAkJCWlmYykKIAkJCQljYXNlICR7QVJDSH0gaW4KIAkJCQkJeDg2 fGlhNjR8YW1kNjQpCkBAIC05NSw2ICsxMDksMTIgQEAKIAkJCQlmMmMpCiAJCQkJCWVlcnJvciAi WyR7aX1dIGVtZXJnZSBkZXYtbGFuZy9mMmMiCiAJCQkJCTs7CisJCQkJcGdmOTApCisJCQkJCWVl cnJvciAiWyR7aX1dIGVtZXJnZSBkZXYtbGFuZy9wZ2ktd29ya3N0YXRpb24iCisJCQkJCTs7CisJ CQkJcGdmNzcpCisJCQkJCWVlcnJvciAiWyR7aX1dIGVtZXJnZSBkZXYtbGFuZy9wZ2ktd29ya3N0 YXRpb24iCisJCQkJCTs7CiAJCQkJaWZjKQogCQkJCQljYXNlICR7QVJDSH0gaW4KIAkJCQkJCXg4 NnxpYTY0KQpAQCAtMTEyLDcgKzEzMiw5IEBACiAJCWVpbmZvICJJbnN0YWxsZWQgYXJlOiAke0FW QUlMQUJMRX0iCiAJCWlmIFsgLW4gIiR7Rjc3fSIgLW8gLW4gIiR7RkN9IiAtbyAtbiAiJHtGMkN9 IiBdOyB0aGVuCiAJCQlpZiBbIC1uICIke0Y3N30iIF07IHRoZW4KLQkJCQlGQz0iJHtGNzd9IgkJ CQkJCSMgRjc3IG92ZXJ3cml0ZXMgRkMKKyAJCQkJaWYgWyAiJHtGNzd9IiAhPSAicGdmNzciIF0g JiYgWyAiJHtGQ30iICE9ICJwZ2Y5MCJdOyB0aGVuCisJCQkJCUZDPSIke0Y3N30iCQkJCQkJIyBG Nzcgb3ZlcndyaXRlcyBGQworIAkJCQlmaQogCQkJZmkKIAkJCWlmIFsgLW4gIiR7RkN9IiAtYSAt biAiJHtGMkN9IiBdOyB0aGVuCiAJCQkJZXdhcm4gIlVzaW5nICR7RkN9IGFuZCBmMmMgaXMgaW1w b3NzaWJsZS4gRGlzYWJsaW5nIEYyQyAhIgpAQCAtMTIzLDcgKzE0NSwxMSBAQAogCQkJCWlmIFsg LW4gIiR7RjJDfSIgXTsgdGhlbgogCQkJCQlNWV9GT1JUUkFOPSIkKGJhc2VuYW1lICR7RjJDfSki CiAJCQkJZWxzZQotCQkJCQlNWV9GT1JUUkFOPSIkKGJhc2VuYW1lICR7Rjc3fSkiCisgCQkJCQlp ZiBbICIke0ZDfSIgPT0gInBnZjkwIiBdOyB0aGVuCisJCQkJCQlNWV9GT1JUUkFOPSIkKGJhc2Vu YW1lICR7RkN9KSIKKyAJCQkJCWVsc2UKKwkJCQkJCU1ZX0ZPUlRSQU49IiQoYmFzZW5hbWUgJHtG Nzd9KSIKKyAJCQkJCWZpCiAJCQkJZmkKIAkJCWZpCiAJCWZpCkBAIC0xNDksMTEgKzE3NSwxMiBA QAogCQlmaQogCiAJCWNhc2UgJHtNWV9GT1JUUkFOfSBpbgotCQkJZ2ZvcnRyYW58Zzc3fGlmY3xp Zm9ydHxmMmN8Zjk1KQorCQkJZ2ZvcnRyYW58Zzc3fGlmY3xpZm9ydHxmMmN8Zjk1fHBnZjkwfHBn Zjc3KQogCQkJCUZPUlRSQU5DPSIke01ZX0ZPUlRSQU59IgogCQllc2FjCiAJZmkKIAl1c2UgZGVi dWcgJiYgZWNobyAiRk9SVFJBTkM6IFwiJHtGT1JUUkFOQ31cIiIKKyAJZWluZm8gIlVzaW5nICRG T1JUUkFOQyIKIH0KIAogIyBwYXRjaF9mb3J0cmFuKCk6Cg==