Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
Not eligible to see or edit group visibility for this bug.
View Bug Activity | Format For Printing | XML | Clone This Bug
There is a lot of little thing to get working for Openfoam (it seems) -nsd (this thing wants a dns server ?) -gcc-4.x (Try to used 3.4.4 anyway ?) How to make this huge behemoth work: -Install the binary package x86,amd64 by hand -Try to compile the thing by hand -Make an ebuild for the 1st to work (binary or source)
gstreamer is a compile dependency
(In reply to comment #0) > There is a lot of little thing to get working for Openfoam (it seems) I have managed to get it working in gentoo. (what a mission) > -nsd (this thing wants a dns server ?) > -gcc-4.x (Try to used 3.4.4 anyway ?) You need gcc401, you must edit the gcc-4.0.1 ebuild to remove tha hard mask -* replace it with -~x86. Unmask the package in package.unmask. Digest the ebuild: ebuild gcc.... digest (After doing am emerge sync it overwrites the modified ebuild) You need the multislot USE flag emerge gcc Don't switch to the new gcc, I don't (don't wanna compile your system with gcc401) > How to make this huge behemoth work: > -Install the binary package x86,amd64 by hand I installed the binaries as they require, mkdir OpenFOAM in your home directory. untar all the openfoam tarballs in /home/user/OpenFOAM. Make a linux directory in /home/user/OpenFOAM/ directory and untar the paraview tarball here. create the following symlink ln -sd /usr/i686-pc-linux-gnu/gcc-bin/4.0.1 /home/user/OpenFOAM/linux/gcc-4.0.1 (after you have emerged gcc-4.0.1) Then you have to modify your PATH environment variable First do: env | nano envsave in your home directory You need to fool openfoam to think you are using gcc401 Create a openfoambashrc file chmod +x it. Create an export PATH="(with the contents of PATH from envsave)" entry in it. Change the entry that points to :/usr/i686-pc-linux-gnu/gcc-bin/3.3.6: to :/home/user/OpenFOAM/linux/gcc-4.0.1: Add another entry: source $HOME/OpenFOAM/OpenFOAM-1.2/.OpenFOAM-1.2/.bashrc and remove the source entry for openfoam from your .bashrc in your home directory. Change the .bashrc file in /home/user/OpenFOAM/OpenFOAM-1.2/ to fix java: Under Linux workstation change JAVA_HOME to JAVA_HOME=/opt/sun-jdk-1.4.2.08 Additionally you need ssh or rsh installed and the deamon running, you need telnet installed: emerge netkit-telnetd The ./foamInstallationcheck thing will probably still tell you that you have the worng gcc installed with ons critical or fatal error but it works for me, it finds the right library files, if you use gcc344 it will fail when you run FoamX because it doesn't find the right library's. When you want to run FoamX first do: source openfoambashrc Remember not to use the terminal is which yu ran openfoam for anything else since the Path is now pointing at the wrong gcc!!! Email me if you require any additional info. > -Try to compile the thing by hand Haven't tried yet > -Make an ebuild for the 1st to work (binary or source) Hope somebody will using the info that I have provided! Dewald
This is great, Thanks a lot for the hint, we also just got the thing working, at the moment I would suggest installing the binaries in /opt/openfoam and then make a symlink to the home directories for the users who need it, this makes the whole system a bit more managable and prevent a 1.2GB copy of everything. What would everyone think ? And I'll ask if someone else is interested in joining this project ...
I'm certainly no expert, I've currently got openfoam running by just following the directions from the website. (Yes, I dropped new versions of gcc and java into my home account... Ugggly way to do things.) Has anything on an ebuild progressed? I'm happy to test things, if that's any help.
I am currently strugling to make a clean installation with not too many duplicates. At the moment Java FoamX is giving me some headache.
I have managed to get openfoam 1.1 working and compiling (after the stable release of gcc 3.4) properly, with only two modifications. I made a simlink in $home/OpenFOAM/linux to gcc: ln -sd /usr/bin/gcc-3.4.4 $home/OpenFOAM/linux/gcc-3.4.3 >>At the moment Java FoamX is giving me some headache. To fix the java problem modify the .bashrc file located in the OpenFOAM-1.1 dir to point the java to java path $JDK_HOME. # Linux workstation # ~~~~~~~~~~~~~~~~~ if [ "$machineTest" = "Linux" ]; then export JAVA_HOME=$JDK_HOME processor=`uname -m` if [ "$processor" = "ia64" ]; then export JAVA_HOME=/usr/java/j2sdk1.4.2 fi Now you will be able to run Allwmake, don't do this as root though. >>at the moment I would suggest installing the binaries in /opt/openfoam and >>then make a symlink to the home directories for the users who need it, this >> makes the whole system a bit more managable and prevent a 1.2GB copy of everything. What would everyone think ? It should be possible to get openfoam to install into the proper dirs by modifiyng the bashrc file located in .openfoam: export WM_PROJECT_INST_DIR=$HOME/$WM_PROJECT #export WM_PROJECT_INST_DIR=~$WM_PROJECT #export WM_PROJECT_INST_DIR=$HOME/$WM_PROJECT/$LOGNAME-$WM_PROJECT_VERSION #export WM_PROJECT_INST_DIR=/usr/local/$WM_PROJECT Instead of using the first line comment that and uncomment the last one! I will start playing around and report my results. Dewald
Hello, Did anyone succeed to build completely the beast from the source? I have at my disposal a "guinea pig" test machine: Pentium III, glibc 2.4 and gcc 4.1. I would be willing to give it a try and help a bit if possible.
To build openFoam 1.3 requires gcc-4.1 which is hard masked, you need multislot in your keywords in /etc/make.conf (so that you can have multiple gcc installations, but on a test machine you could possibly skip this, I wouldn't do it though), then you need to unmask it in /etc/portage/package.unmask by inserting =sys-devel/gcc-4.1.0-r1 additionally it is masked by the ~x86 keyword as well so in /etc/portage/package.keywords insert =sys-devel/gcc-4.1.0-r1 Then of course you need to emerge gcc... On a test machine one could switch the compiler to gcc-4.1 if you aren't going to compile anything else on the machine, otherwise you could break stuff.. I have managed to compile openFoam 1.1 from source after gcc 3.4 became stable. It is possible but still requires you to edit the bashrc file located in /$HOME/OpenFOAM/OpenFOAM-1.3/.OpenFOAM-1.3/.bashrc You need to edit the env variables to point to the correct location off gcc, by default the bashrc file it to $HOME/OpenFOAM/linux/gcc It is possible to do a installation to /usr, but to manage that will require additonal tweaking of openFoam's bashrc files. I intend to look into getting openFoam 1.3 compiled and running, I will just have to sort out how to do this without switching the compiler with gcc-config, ie edit the bashrc file # Compiler (if set to "" use the system compiler) # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ export WM_COMPILER=Gcc4 to something like export WM_COMPILER=Gcc-4.1-r1 or something. When I have this up and running I will report back. Then I will look into the relocalisation of openFoam to /usr Dewald
I see on gentoo newsletter that gcc 4.1.1 is going to ber marked unstable this week, so I will be switching soon. That means we can start to work on this seriously. The only issue I can see is a lack of an ebuild for paraview. Foam can run without paraview, but that is like walking around blind folded. Installing the binary with an ebuild should be easy. There already exists a bug for paraview. The other dependies are java, rsh or ssh and telnet. Then foam needs to be relocated to /usr via the foam bashrc files. Just have to check for any lam mpi or such dependencies. I hope to have something up within this week. Dewald (In reply to comment #8) > To build openFoam 1.3 requires gcc-4.1 which is hard masked, you need
How about adding it as a depend ? bug 118130
Created an attachment (id=87505) [details] A start to an ebuild for OpenFOAM-1.3 I hope this can be regarded as a start, it downloads the openfoam source when you digest the ebuild, it goes in /usr/local/portage/sci-misc/OpenFOAM/ It still needs a lot of work: Change it so that rsh or ssh and not both are runtime dependencies Change it so that a jre is a runtime dependency not just blackdown-jre I thought for creating a cluster use flag, that by default is disabled and causes the ebuild only to check for telnet, ie non cluster usage. The cluster use flag could then be used to enable the ssh/rsh dependency for cluster usage. Unfortunately it is all that I had time for. We might have to go with a binary for paraview that this depends on as a runtime depency as well. The mayavi, brl-cad and the people working on paraview have a problem with the use of system vtk libs. Enjoy Dewald
Hello, Nice to see that things are moving forward... So, as I said previously, I am more than willing to give a helping hand with all of this and test things out. I have at my disposal an amd64 based machine (gcc 3.4.5, nvidia video card) and I also have a "guinea pig" x86 (Pentium 3 600MHz, gcc 4.1.0, nvidia video card). The 'guinea pig' will be updated this week (Celeron 3.3GHz, gcc 4.1.1, ATI video card) so, compilation time will be greatly reduced on this box. I mentionned the video cards thinking about OpenGL and visualisation. Here are my thoughts: - Paraview depends on VTK which depends on mpich (for clustering) - OpenFOAM depends on lam-mpi and guess what... one cannot have both on the same machine time... This is one problem to be dealt with if we consider clustering (or simply dual-core processors) - The OpenFOAM souce code contains copies of other packages: - lam-7 (lam-mpi in gentoo world) - mico - zlib and probably others that I have not identified yet. What would be nice is to use existing packet instead of recompiling already existing libraries / utilities. This would save some compilation time and make the whole thing more 'gentoo-spirited' Daniel
I have tried to build OpenFOAM 1.3 on a Pentium III with gcc 4.1 and glibc 2.4. I use the Allwmake command. After _many_ hours of compilation it says so (this error being present a few times before): SOURCE_DIR=. SOURCE=foamInfoExec.C ; g++ -m32 -Dlinux -DDP -Wall -W -Wno-unused-parameter -Wold-style-cast -O3 -DNoRepository -ftemplate-depth-30 -I/home/ted/OpenFOAM/OpenFOAM-1.3/src/OpenFOAM/lnInclude -IlnInclude -I. -fPIC -pthread -c $SOURCE -o Make/linuxGcc4DPOpt/foamInfoExec.o /home/ted/OpenFOAM/OpenFOAM-1.3/wmake/bashScripts/mkObjectDir /home/ted/OpenFOAM/OpenFOAM-1.3/applications/bin/linuxGcc4DPOpt/foamInfoExec g++ -m32 -Dlinux -DDP -Wall -W -Wno-unused-parameter -Wold-style-cast -O3 -DNoRepository -ftemplate-depth-30 -I/home/ted/OpenFOAM/OpenFOAM-1.3/src/OpenFOAM/lnInclude -IlnInclude -I. -fPIC -pthread Make/linuxGcc4DPOpt/foamInfoExec.o -L/home/ted/OpenFOAM/OpenFOAM-1.3/lib/linuxGcc4DPOpt \ -lOpenFOAM -liberty -o /home/ted/OpenFOAM/OpenFOAM-1.3/applications/bin/linuxGcc4DPOpt/foamInfoExec /usr/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../i686-pc-linux-gnu/bin/ld: cannot find -lOpenFOAM collect2: ld returned 1 exit status make: *** [/home/ted/OpenFOAM/OpenFOAM-1.3/applications/bin/linuxGcc4DPOpt/foamInfoExec] Error 1
Created an attachment (id=89196) [details] OpenFOAM-bin-1.3.ebuild This is a temporary "binary" ebuild. It installs the source and binaries to /opt/OpenFOAM-1.3/ The reason I went this route is to facilitate this whole ebuild writing and OpenFOAM compiling process without affecting our systems (I am still learning so trial and error happens a lot!), later on we drop the whole binary thing. For those just intrested in the binary version this is the incomplete answer. I have an ebuild for paraview-bin as well, e-mail me if you want it. This ebuild only makes provision for x86 not amd64, could someone with the appropriate arch perhaps do us this favour. The bashrc files still need to be figured out and patched.
(In reply to comment #13) > /home/ted/OpenFOAM/OpenFOAM-1.3/applications/bin/linuxGcc4DPOpt/foamInfoExec > /usr/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../i686-pc-linux-gnu/bin/ld: > cannot find -lOpenFOAM > collect2: ld returned 1 exit status > make: *** > [/home/ted/OpenFOAM/OpenFOAM-1.3/applications/bin/linuxGcc4DPOpt/foamInfoExec] > Error 1 > Make sure you get a clean bill of health from foamSystemCheck
(From update of attachment 89196 [details]) This ebuild depends on gcc-4.1 and paraview-bin
Created an attachment (id=89687) [details] OpenFOAM-bin-1.3.ebuild This still depends on paraview-bin. The previous ebuild missed all the hidden files and directories, hoped this one doesn't miss any.
(In reply to comment #15) > (In reply to comment #13) > > /home/ted/OpenFOAM/OpenFOAM-1.3/applications/bin/linuxGcc4DPOpt/foamInfoExec > > /usr/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../i686-pc-linux-gnu/bin/ld: > > cannot find -lOpenFOAM > > collect2: ld returned 1 exit status > > make: *** > > [/home/ted/OpenFOAM/OpenFOAM-1.3/applications/bin/linuxGcc4DPOpt/foamInfoExec] > > Error 1 > > > Make sure you get a clean bill of health from foamSystemCheck What do you mean? I have at my disposal an AMD64 box. If you tell me what I should modify from what you did, I can try to make a paraview-bin for this architecture
> -nsd (this thing wants a dns server ?) There is an ebuild for nsd in the sunrise overlay, see: http://gentoo-sunrise.org/cgi-bin/trac.cgi This is one of things hindering my current effort!
Created an attachment (id=90384) [details] OpenFOAM-bin-1.3.ebuild My latest effort! I will upload the files to the bashrc files with. Still not there, my ebuild writing skills doesn't yet include patching, so if someone else knows how, please!
Created an attachment (id=90385) [details] File to patch ../OpenFOAM-1.3/.bashrc with
Created an attachment (id=90386) [details] File to patch ../OpenFOAM-1.3/.OpenFOAM-1.3/bashrc with
Created an attachment (id=91150) [details] OpenFOAM-bin-1.3.ebuild Ignore any previous comments of mine about nsd, just ensure that /etc/init.d/nscd is running, I updated dependencies of the ebuild to include dev-libs/libelf. With 1.2 the libraries are compatible and seem to work with 1.3 however I still need to sort out an invalid ELF header on libz.so. OpenFOAM 1.2 compiles and seems to run fine.
Paraview is now available in portage, although in the unstable tree, but it is.
I did not really try a ebuild you supplied, just played a bit with installation in my home directory (as suggested by OpenFOAM developers). just want to share my experience. > Ignore any previous comments of mine about nsd, just ensure that > /etc/init.d/nscd is running, I updated dependencies of the ebuild to include > dev-libs/libelf. you do not really need to install neither nsd, nor dev-libs/libelf to run OpnedFOAM from prebuild binary (as well as I understood, your ebuild is for binary installation). nsd seems to be already included in OpenFOAM distribution (at least, I did not install net-dns/nsd). dev-libs/libelf is blocked by dev-libs/elfutils which used by sys-devel/prelink. dev-libs/elfutils is a drop-in replacement of dev-libs/libelf, only one thing was missing on my installation of elfutils: a symlink libelf.so.0 -> libelf.so.1 in /usr/lib it is mentioned in the documentation that OpenFOAM compillation against mpich instead of lam-mpi is possible (I didn't try), see also discussion http://bugs.gentoo.org/show_bug.cgi?id=44132 about installation of different mpi implementations.
FreeBSD team done good job: http://www.freshports.org/science/openfoam I'm not good in ports, but it seems they made system-wide installation, compiled against mpich2 or lam-mpi, compiled with system java-1.5... are there FreeBSD experts in here? maybe it is easier to rewrite this port to ebuild then do it from scratch?
Created an attachment (id=135019) [details] changes sourcing files for compiling This patch does some changes, to .bashrc and .OpenFOAM-1.4.1/bashrc, so that it can be sourced for compilation and after that for installation in the system.
Created an attachment (id=135020) [details] mico patch for compilation This is only used when the mico useflag is active, in addition to the compile patch.
Created an attachment (id=135022) [details] this patches some sources This patch was extracted from the svn.
Created an attachment (id=135024) [details] Ebuild for OpenFOAM-1.4.1 This ebuild comes with several new USE-Flags. The parafoam USE-Flag doesn't work at the moment for me! Please change the AssignedTo to "maintainer-wanted@gentoo.org".
This overlay is from now on also available via the sunrise overlay.
example from tutorial doesn't work because some paths are not in PATH/LDPATH, adding WM_PROJECT_DIR=/usr/lib/OpenFOAM/OpenFOAM-1.4.1 PATH=/usr/lib/OpenFOAM/OpenFOAM-1.4.1/applications/bin:/usr/lib/OpenFOAM/OpenFOAM-1.4.1/bin LDPATH=/usr/lib/OpenFOAM/OpenFOAM-1.4.1/lib:/usr/lib/OpenFOAM/OpenFOAM-1.4.1/lib/openmpi-1.1.2 to /etc/env.d/50openfoam doesn't help, WM_PROJECT_DIR still missing
Which ebuild do you use? This one or the one from the sunrise overlay? You have to source /usr/lib/OpenFOAM/bashrc, which should be a symbolic link to /usr/lib/OpenFOAM/OpenFOAM-1.4.1/.OpenFOAM-1.4.1/bashrc In this file are set most of the environment variables, as well as WM_PROJECT_DIR. If you are using a 64bit Operating system, then WM_64="on" should be set in your ~/.bashrc, if you are using the bash.
I used ebuild from sunrise. source /usr/lib/OpenFOAM/bashrc works (did not checked simulation results though). probably it is good idea to add some note or ewarn to ebuild like "in order to use OpenFOAM add [ -r /usr/lib/OpenFOAM/bashrc ] && source /usr/lib/OpenFOAM/bashrc string to your ~/.bashrc"
Oliver, What a great job you did! I have installed OpenFOAM on my x86 gcc4.1.2 box yesterday and the build went flawlessly. Very very nice, considering how _big_ OpenFOAM is. I initiated the Paraview and the OpenCascade ebuilds. OpenFOAM was on my list as well, but I never found the energy to achieve what you did... ;) A few comments so far: - I am a bit confused with the parafoam flag and the way it is designed to work. Can you develop a bit? - I fully agree with Maxim's comment (#34) - OpenFOAM has its own file structure apparently. Shouldn't it be installed under /opt for instance, instead of /usr/lib/openfoam (sorry by memory)? - In the same spirit, do you think that it would be possible to find all the components of Openfoam in the classical Unix structure (that is to say, directly under /usr such that, for instance binaries are under /usr/bin and not /opt/openfoam/bin or /usr/lib/openfoam/bin )? - I have at my disposals an x86 gcc3.4 box and an amd64 gcc3.4 box. Gcc4.x is installed on the boxes but this is _not_ the primary compiler. Do you think the ebuild will work and find/flag by itself the right gcc? OpenFOAM expect gcc4, isn't it? Daniel
Hello, I am trying to run the icoFOAM testcases (see http://www.csc.fi/english/research/sciences/CFD/CFDsoftware/openfoam/cavituto) The computation part seems to run fine, however I do not really know how to visualize the results. I have paraview 2.6.2 which has been built on my machine previously. [ebuild R ] sci-libs/openfoam-1.4.1_p20071028 USE="doc examples hdf5 python threads -lam -metis -mico -mpi -mpich -parafoam" 0 kB [1] I tried FoamX but I get the following: Starting NameServer with inet:mhordraid:1234 ... /usr/lib/OpenFOAM/OpenFOAM-1.4.1/bin/runFoamXHB: line 130: nsd: command not found I built with nsd from the sunrise tree but the application ends up under /usr/sbin, so it is unreachable to me as a standard user. Any idea? Daniel
The problem is the libPVFoamReader. For this lib you need the ParaView Sources and you have to configure ParaView. Nevertheless you need some (small) binaries, which you can build or can copy from the existing Paraview installation. Once you have all this, it *should* be possible to build this library. Unfortunately this doesn't work at the moment inside the sandbox environment. But it works for me outside. The other option is to build this lib, when you are building Paraview. But the OF must be present because, it links against some OF lib's. But to visualize you have two options: - use the existing OF functionalities in Paraview. - use openfoam_to_vtk, and open the vtk's in PV I've added an additional elog to the ebuild. (comment #34) I think only prebuild binaries should be installed under /opt. You're right with the file structure. But then then aim must be, that you don't need anymore to source any file. But when you are sourcing the bashrc, then there are set at least 50 PATH's. And I don't know where they are all used. (Maybe also outside from the OF env). OpenCFD said, they had use gcc4.2 to compile OF1.4.1. I don't know if it's working with gcc3.X. I have to do the following to get FoamX running: mkdir -p ~/.OpenFOAM-1.4.1/apps cp -r /usr/lib/OpenFOAM/OpenFOAM-1.4.1/.OpenFOAM-1.4.1/apps/FoamX ~/.OpenFOAM-1.4.1/apps source /usr/lib/OpenFOAM/bashrc I haven't seen any nsd Problems yet.
Oliver, > I have to do the following to get FoamX running: > > mkdir -p ~/.OpenFOAM-1.4.1/apps > cp -r /usr/lib/OpenFOAM/OpenFOAM-1.4.1/.OpenFOAM-1.4.1/apps/FoamX > ~/.OpenFOAM-1.4.1/apps > source /usr/lib/OpenFOAM/bashrc > > I haven't seen any nsd Problems yet. This did not work for me. It still complains about nsd. Daniel
> But to visualize you have two options: > - use the existing OF functionalities in Paraview. I did not find any. Where are they? > - use openfoam_to_vtk, and open the vtk's in PV I did not find this command either. Regarding nsd, do you have it installed and configured somehow? Daniel
Well, in Paraview 2.6.2: File -> Open Data: As type you should choose All Files (*). Then you had to open the controlDict file from your computation. And choose as filter the "OpenFOAM Files Reader". The name of the utility is called foamToVTK. Then you can open the vtk Files. Till now, I've not installed nsd nor configured them. Maybe it was installed as dependency.
Hello Daniel, the binary /usr/bin/nsd is provided by the net-misc/mico package at least in version 2.3.12. I've putted this ebuild back to the sunrise overlay and have maked an mico USE-Flag in the OF ebuild. Since the mico ebuild is now in the reviewed sunrise tree, I think I can purge now the mico USE-Flag from the OF-ebuild. Oliver
Created an attachment (id=140130) [details] binary ebuild for OpenFOAM-1.4.1 This ebuild installs the binaries, which are available from sourceforge. For execution it requires at least gcc-4.2. And for paraFoam support paraview-2.4.* has to be installed, because the libPVFoamReader is compiled against this version! But you can also use the native OF support in paraview-2.6*. Please rename the openfoam-1.4.1_p20071028.patch to openfoam-bin-1.4.1_p20071028.patch, this ebuild requires this patch (it's the same as in the source ebuild - just another name). Oliver
Looking for a maintainer
Hello, there are three possibilities to install OpenFOAM: - the OpenFOAM-***.ebuild (installs the whole package) - the OpenFOAM-bin-***.ebuild (installs the binaries from Sourceforge) - the OpenFOAM-meta-***.ebuild (installs each component [wmake, kernel, solvers, utilities] of openfoam separately - faster if only one component has to be updated) You can find the newest version of each ebuild here: http://overlays.gentoo.org/proj/sunrise/browser/reviewed/sci-libs
I used the OpenFOAM-meta ebuild to build from source, and it worked on the first try! I ran some tutorials to verify that it runs. FoamX works, but paraFOAM does not appear to get built. I used Paraview 3.2.1 with the OpenFOAM filter to import the controlDict file as suggested by Oliver Borm. A few questions and suggestions: 1. Is Java really a runtime dependency for all the components? According to OpenCFD, it should only be required to build and run FoamX. 2. openFOAM-wmake ebuild has runtime dependencies on Paraview and sun-java3d-bin. I really doubt those are required to build wmake. 3. I would suggest adding a number of USE flags: one to install the tutorials, another to build FoamX, another to choose lam or mpichand another to build paraFoam. Personally, I would prefer not to build FoamX if that could eliminate the Java requirement. I would like to test my ideas for the ebuild, but I won't get to it for a few weeks. Thanks for your work on this!
Great job! The meta-ebuild compiled for me on amd64 without an issue :) - I talked with some guys who are on other platforms and they are thorougly impressed. I confirm the issue in comment #45 - parafoam is not built. And thx, Oliver for comment #40 - took me a while to figure out how to open cases in paraview (vtkToFoam and creating a symlink.foam to the controlDict doesn't work too well for me).
Created an attachment (id=161142) [details] Version bump to OpenFOAM 1.5 This is a new ebuild for OpenFOAM-1.5
Created an attachment (id=161144) [details] Version bump to OpenFOAM 1.5 (binary version) This is a version bump to OpenFOAM 1.5 (binary version)
Created an attachment (id=161146) [details] Patch for the OpenFOAM 1.5 ebuilds Patch for the OpenFOAM 1.5 ebuilds
openfoam-1.5.ebuild contains ${WM_OPTIONS} in install path src_install(), this leads to errors during installation: >>> Install openfoam-1.5 into /var/tmp/portage/sci-libs/openfoam-1.5/image/ category sci-libs install: cannot stat `applications/bin/linuxGcc/*': No such file or directory install: cannot stat `lib/linuxGcc/*': No such file or directory and thus libraries and solvers are not installed. removing this part should fix the problem, since openfoam does not put the stuff in these directories.
Hello Maxim, thanks for testing. You are right. I have just uploaded the new ebuild to the sunrise overlay: http://overlays.gentoo.org/proj/sunrise/browser/sunrise/sci-libs/openfoam/openfoam-1.5.ebuild
Created an attachment (id=165206) [details] improved ebuild I propose an improved ebuild, based on my experience to install openfoam in prefix gentoo. some comments: 1. neither paraview nor opendx is required to compile and use this library. these tools are used for postprocessing only, but other packages could be used also. 2. it is better to source bashrc of particular OpenFOAM version 3. fix some hardwired paths (necessary mainly for prefix, but anyway) 4. install tutorial and sources in proper places and keep OpenFOAM directory structure if USE=examples is set, without sources with provided headers, one basically unable to use library
Hi guys Remember to version bump openfoam-meta as well otherwise is doesn't update the rest of the packages ie openfoam-meta-1.5_p20090311.ebuild Dewakd
So I got bored and transferred the ebuilds from sunrise. Which means that we can close this bug at last ... feel free to throw further improvements my way :)
