Bugzilla Bug 77197

This is a brl-cad ebuild which is close to working, but encounters some sandbox
violation during the make install portion.  Help appreciated

Created an attachment (id=48000) [details]
Ebuild for brl-cad 7.0.2

This one has sandbox problems

Sandbox problems (apparently) stem from $(DESTDIR) variable not being used in
the install-data-hook logic in the following Makefiles:

libtcl/doc/Makefile
libtk/doc/Makefile
incrTcl/itcl/doc/Makefile
incrTcl/itk/doc/Makefile
iwidgets/doc/Makefile

So fixing this should solve the sandbox issue.  If this change makes sense in
the upstream I'll just bump the ebuild version, otherwise I can try and figure
out the patches.

Things to fix:

* KEYWORDS needs to be set as per policy
* Fix IUSE
* Don't hardcode version numbers
* No econf?

> Things to fix:

> * KEYWORDS needs to be set as per policy

OK.  In theory I suppose this should build on a lot of different archs, but the only one I can test on is x86.  Any volunteers?

> * Fix IUSE

Opps, forgot to remove tcltk.

> * Don't hardcode version numbers

Did I?  You mean this? :
  S="${WORKDIR}/${PN}-7.0"

Unfortunately the build directory doesn't open up into the full 7.0.2 - the tarball just expands into 7.0.  I don't see a way around hard coding that particular part - is there one?

> * No econf?

Uh - just used what had worked for the normal build, didn't think about econf.  I suppose it should work - I'll give it a try.

I guess I can go ahead and try to generate patch files for this - hopefully it will be of enough interest to merit quick insertion into portage once the ebuild is working.

KEYWORDS -- policy says they should be ~arch to begin with, so you want ~x86.

Version numbers -- use either bash substitution or versionator to remove the final version component.

Ah, OK.  ~x86 it is.

Um - is there documenation somewhere for the versionator eclass?  Also, is it really worth it to make that part of the ebuild non-hard coded?  I guess if policy dictates it I can try but it seems sort of silly.  I might even see if the developers of brl-cad could switch to using the full version number - that might be the simplest thing.

man 5 versionator.eclass (part of portage-manpages). Worth doing, it saves all
kinds of pain when doing version bumps.

Created an attachment (id=48159) [details]
Updated ebuild

Created an attachment (id=48160) [details]
Patch for Makefile.am errors (this isn't all of them, apparently)

OK, the build gets further into the install process now, but I'm hitting a
stubborn sandbox error:

Making install in pro-engineer
make[2]: Entering directory
`/var/tmp/portage/brlcad-7.0.2/work/brlcad-7.0/misc/pro-engineer'
make[3]: Entering directory
`/var/tmp/portage/brlcad-7.0.2/work/brlcad-7.0/misc/pro-engineer'
make[3]: Nothing to be done for `install-exec-am'.
/bin/sh ../../misc/mkinstalldirs /usr/lib/../pro-engineer
 /bin/install -c -m 644 install.doc /usr/lib/../pro-engineer/install.doc
ACCESS DENIED  unlink:    /usr/pro-engineer/install.doc
/bin/install: cannot remove `/usr/lib/../pro-engineer/install.doc': Permission
denied
 /bin/install -c -m 644 protk.dat /usr/lib/../pro-engineer/protk.dat
ACCESS DENIED  unlink:    /usr/pro-engineer/protk.dat
/bin/install: cannot remove `/usr/lib/../pro-engineer/protk.dat': Permission
denied
make[3]: *** [install-proeDATA] Error 1
make[3]: Leaving directory
`/var/tmp/portage/brlcad-7.0.2/work/brlcad-7.0/misc/pro-engineer'
make[2]: *** [install-am] Error 2
make[2]: Leaving directory
`/var/tmp/portage/brlcad-7.0.2/work/brlcad-7.0/misc/pro-engineer'
make[1]: *** [install-recursive] Error 1
make[1]: Leaving directory `/var/tmp/portage/brlcad-7.0.2/work/brlcad-7.0/misc'
make: *** [install-recursive] Error 1

!!! ERROR: sci-misc/brlcad-7.0.2 failed.

I can't seem to find a simple answer for this one, so I guess I'll have to keep
looking unless someone smarter than me finds it first.

Uh, silly question, but I just realized this got assigned to the graphics herd.
 I would have thought this would be likely to go into the sci-misc section,
along with qcad.  gCAD3D was assigned to sci, as well.  Am I missing something?
 brl-cad is an engineering/science program much more than it is a graphics
program.

Who decides where to assign things?  Is the point up for discussion?

OK, the 7.0.4-2 release builds successfully on gentoo, thanks to the efforts of
the primary developer.  Hence the new ebuild without patches should work, with
the possible exception of not pointing to the correct file on sourceforge.  If
I need to I'll sort that out once the update is released, but based on latest
cvs test this one is ready to go.

As mentioned, I think because of the nature and intended use this should be
included in qcad's category.  That said, thanks a bunch for the help I have
recieved on this ebuild from the gfx herd :-).

Created an attachment (id=49606) [details]
Ebuild for 7.0.4 revision 2. 

Probably a naming convention error.  7.0.4-2 builds successfully on gentoo. 
Not sure what the tarball will be called on sf yet - just had the successful
test of cvs.

Created an attachment (id=49673) [details]
ebuild - 7.0.4	Works with sf tarball

OK, the sourceforge tarball has been fixed, and now builds without trouble
using this ebuild.  It should be ready to go.

Hmm - apparently this ebuild caused some subtle problems on my system due to
name conflicts in library names.  Need to put this one on hold while this is
figured out.  DO NOT INSTALL.  (it may not work on an uncorrupted system
anyway)

Created an attachment (id=59334) [details]
brlcad-7.2.4.ebuild written from scratch

the 7.0.4 version ebuild is a crap
i written a new one, hope this will be better, although still there are some
issues:
1) the Utah Raster Toolkit should be in a seperate ebuild, but as long as it is
not used by any other package in portage, we can defer this separation, as long
as there is no volunteer to do urt ebuild.
2) i hope i cleaned all the junk that brl-cad puts in your system, but i am a
big lame, so some pro should check the CONTENTS file.
3) it needs a rather ugly hack patch to configure script, becouse the
AC_TRY_RUN  for iwidgets is broken, i will notice upstream about this problem. 


i never used bugzilla before, so if i screwed something, than sorry
the brlcad-7.2.4-gentoo.diff follows in the next post

Created an attachment (id=59335) [details]
brlcad-7.2.4-gentoo.diff needed for brlcad-7.2.4.ebuild

ugly ugly ugly

hmm, shouldn't there be a seperate folder in portage for CAD/CAM/CSG
(like sci-cad) there are many packages that would fit there, qcad, brl-cad,
varicad, linuxcad, microstation. Some are just waiting to get a proper .ebuild.

If the build breaks, its probably due to missing symlinks
/usr/lib/libitcl-3.x.so and /usr/lib/libitk-3.x.so. Try to use itcl-3.3 and
itk-3.3 ebuild from bugzilla:
http://bugs.gentoo.org/show_bug.cgi?id=93307
http://bugs.gentoo.org/show_bug.cgi?id=93311
Feedback is welcome and needed.

If u want to try brlcad-7.2.4.ebuild, u need the itcl-3.3.ebuild ( BUG 93307 )
and itk-3.3.ebuild ( BUG 93311 ).

Created an attachment (id=60113) [details]
brlcad-7.2.4.ebuild (  updated dependences and new debug use flag )

* brlcad-7.2.4 depends now on itcl-3.3 ( BUG 93307 ) and itk-3.3 ( BUG 93311 ).

 ( becouse brlcad configure states that libtcl and libtk is in /usr/lib, 
   this is wrong so symlink is needed in itcl and itk ebuild.
   And of course the itcl and itk are now split )
* new debug use flag added

Diff:
--- brlcad-7.2.4.ebuild.old	2005-05-29 18:58:56.551739216 +0000
+++ brlcad-7.2.4.ebuild 2005-05-29 19:06:13.232353672 +0000
@@ -11,15 +11,15 @@
 LICENSE="GPL LGPL GFDL BSD"
 SLOT="0"
 KEYWORDS="~x86"
-IUSE="java jove pic"
+IUSE="java jove pic debug"

 DEPEND="virtual/x11 \
	>=dev-lang/tcl-8.4 \
	>=dev-lang/tk-8.4 \
	media-libs/libpng \
	sys-libs/zlib \
-	>=dev-tcltk/itk-3.1 \
-	>=dev-tcltk/itcl-3.1 \
+	>=dev-tcltk/itk-3.3 \
+	>=dev-tcltk/itcl-3.3 \
	>=dev-tcltk/iwidgets-4.0.0 \
	jove? ( app-editors/jove ) \
	java? ( virtual/jdk ) \
@@ -47,6 +47,10 @@
		myconf="${myconf} --enable-jove"
	use pic && einfo "Configuring for pic code." &&
		myconf="${myconf} --with-pic"
+	use debug && einfo "Debuging support enabled" &&
+		myconf="${myconf} --enable-debug" ||
+		myconf="${myconf} --disable-debug"
+
	BC_RETRY=no econf $myconf || die "econf failed"
	emake || die "emake failed"
 }

It seems that at least in 7.2.6 the source file has a built-in version of tcl,
inctTcl ans iwidgets, so maybe those dependencies can be optional, freeing this
ebuild fronm dependency on other bugs?

BUG 93307 and BUG 93311 now closed, using buildin tk/tcl/iwidgets IMHO is not a
good practice. However if its brl-cad.ebuild in portage or nothing we can add
special USE flag lets say 'builtin_tcl'. Any pros or cons?

It would be a good idea to allow the use of the builtin version which is sure
to
work, in case the external stuff is not working for some reason (e,g, upgraded
to an incompatible version). Other than that, it doesn't seem very important.

Created an attachment (id=63117) [details]
Portage log for failed brlcad emerge

I'm having some trouble emerging this package.
Attached is the portage log, followed by 'emerge info' output.
It seems to fail with some undefined references to itk and itcl functions.

Created an attachment (id=65719) [details]
emerge info (for successful brlcad build)

brlcad compiles successfully for me--see attached output from "emerge info".  I
tried some simple TCL commands in brlcad and they were successful.  I am using
itcl 3.3 and itk 3.3 (despite the face that itk is masked).

I am thinking about packaging whole brlcad-7.4.2 into /usr/brlcad (in contrast
to puting all files in /usr/bin /usr/share and similar directories). Its a big
package, and in binary form on sourceforge it exposes such behaviour :)
Please let me know what you think, becouse trying to contact gentoo devs on irc
is pointless :P

Another question comes from the fact that brlcad or brl-cad is known by two
names.
Eg:
Sourceforge project name: BRL-CAD ( but webpage brlcad.sourceforge.net )
Sourceforge tarballs: brlcad-...
Freshmeat: BRL-CAD
Webpage: brlcad.org (bu the banner says BRL-CAD)
IRC: #brlcad on freenode

Now, which one seems cooler to you? :]

I think using /usr/brlcad is OK; just like qt, kde, and other big ones. 

As for package names, I'd say 'brlcad' since it's less typing :-) and also named
like the directory it will be installed under if it's going to be in
/usr/brlcad. The official names don't really matter because usually ebuilds are
named to match the package filename better (this way $P is usable immediately).

According to "friendly" FHS < http://www.pathname.com/fhs/pub/fhs-2.3.html >
we can only use /opt/brlcad or /usr/{bin,lib,share,include}, however its gentoo
tradition to screw FHS :] Any cons or pros about /opt?

Binary sourceforge tarball brlcad-7.4.0_linux_ia32.tar.bz2 installs to
/usr/brlcad, not only gentoo screws FHS :]

(In reply to comment #27)  
> I am thinking about packaging whole brlcad-7.4.2 into /usr/brlcad (in  
contrast  
> to puting all files in /usr/bin /usr/share and similar directories). Its a  
big  
> package, and in binary form on sourceforge it exposes such behaviour :)  
> Please let me know what you think, becouse trying to contact gentoo devs on  
irc  
> is pointless :P  
>   
I think that this would be a bad idea - please read Gentoo policy on this. On  
the whole we do try to stick to FHS, but there are specific cases where this  
has not been done. Take a look at the newer xorg-x11 ebuilds that have  
rectified this, and the masked qt-4 ebuilds. KDE itself does not to allow  
multiple major revisions to be installed on the same system.  
  
Contacting us on IRC is not pointless, there are some of us in #gentoo-science.  
The thing is that there aren't very many sci devs, and so we will not respond  
instantly all the time. We have real lives, jobs and stuff making us unable to  
constantly monitor IRC. Please read the FHS and the Gentoo developer docs  
- /opt is for binary packages, /usr is for stuff compiled by the distro.  
  
There is also a mailing list for discussing scientific Gentoo applications  
which can be found on the web site. I would not be inclined to add a new ebuild 
not complying to the FHS unless there is a very good reason for doing so. The 
ones not obeying it now are in general trying to correct this where possible. 

(In reply to comment #32)
> Contacting us on IRC is not pointless, there are some of us in #gentoo-science.  
> The thing is that there aren't very many sci devs, and so we will not respond  
> instantly all the time. We have real lives, jobs and stuff making us unable to  
> constantly monitor IRC. Please read the FHS and the Gentoo developer docs  
> - /opt is for binary packages, /usr is for stuff compiled by the distro. 
Forgive me being not polite, but it seamed to me that science heard is not
interested in brlcad, and my work will go >/dev/null. If You say that we need to
comply to FHS than so shell it be.

>   
> There is also a mailing list for discussing scientific Gentoo applications  
> which can be found on the web site. I would not be inclined to add a new ebuild 
> not complying to the FHS unless there is a very good reason for doing so. The 
> ones not obeying it now are in general trying to correct this where possible. 

I will subscribe imidietly, thank you for your profesional assistance, and
please accept my appologies.

Created an attachment (id=67659) [details]
brlcad-7.4.2-gentoo.diff

configure.ac fixes:
 * --datadir fix
 * tk detection fix
 * iwidgets detection fix

Created an attachment (id=67660) [details]
brlcad-7.4.2.ebuild

remember to:
 * use urt-3.1b.ebuild available in bugzilla ( BUG 104738 )
 * setup TCL_LIBRARY variable ( BUG 104769 )

Thx to brlcad team for their great support in fixing problems.
Rumors say of brlcad-7.6.0...

(In reply to comment #24)
> It would be a good idea to allow the use of the builtin version...
(tk/tcl/itk/itcl/iwidgets)
If we want to stick to FHS there is no way to use builtin versions.
Try to imagine the hell that will happen when library names are in conflict, all
the linker confusion, etc. Of course we could try to do some heavy voodoo in the
ebuild, but i think that would do more harm than good.

Indeed, this built-in vs. installed conflict was one of the original reasons I  
wiped out my system with the first trials.  However, I gather this is not done  
idly on the brl-cad side, and they have reasons for doing this.  It is a hard  
problem, and one I do not see a clear solution for at the moment.  

My preferred solution was to put the built-in libs in /usr/lib/brlcad or some  
such and have the brlcad binaries (and only the brlcad binaries) 
use /usr/lib/brlcad before /usr/lib, but a) I don't know if this is workable b) 
even if it is I don't know how to do it and c) it might not get the approval of 
the powers that be. 

It may be that brl-cad is simply incompatible with gentoo as things currently 
stand. :-( 

In reply to #37.
Wrong. Wrong. Wrong.

It is 100% compatibile now :]. Not a single builtin lib needed :] Try the 7.4.2
ebuild and you'll see, the configuration accepts econf defaults gladly. All of
the changes needed for the original source tarball are mainly typo fixes. They
are commited to CVS and will be included in the next brl release.

The separation of tcl/tk/itcl/itk/iwidgets was very hard for brl cad team mainly
becouse of changes needed in the tk library itself. However with the help of
AFAIK debian and gentoo developers, all of modifications to the tk (
tkBezierCanvas ) were split into libtclcad library ( they are going to be
integrated back to tk lib one day ). This split still requiers internal headers
of tk library to implement tkBezierCanvas as a normal tkCanvas, so there is no
way it can be seperated from the main tarball ( otherwise we could not compile
libtclcad, becouse in gentoo tkInt.h and freinds are sent to >/dev/null after tk
installation ) The brlcad build still uses build-in tk/tcl version by default,
but... rummors say that in 7.6 such behaviour will be droped, it is left that
way only for the testing period.

Request from Yosef (comment #24) was just an idea how to avoid unwanted
dependencies on itk and itcl-3.3 and urt. However itk and itcl is in portage (
just unmask, it they work great ) and i submited initial urt ebuild to bugzilla
BUG 104738 ( i hope it will find a maintainer one day :P ). There is a BUG
104769 related to TCL_LIBRARY variable, u need to set it up for the build proces
( and any other normal TCL app? ) to work corectly.

Created an attachment (id=67737) [details]
CONTESTS of brlcad image genereted by brlcad-7.4.2.ebuild

No collisions with any gentoo package on my system.

Meaning of "Not a single builtin lib needed" is "library external to brlcad
project".
Please test this ebuild, as only thruout testing can reveal all of the problems
that can still emerge.

Created an attachment (id=68339) [details]
brlcad-7.4.2-system-tcl.diff

Got brlcad-7.4.2.ebuild working...eventually.

Originally failed during 'configure' while testing for libitcl. I set up the
TCL_LIBRARY env variable and did env-update and source /etc/profile, my
config.log showed that it definately had TCL_LIBRARY defined correctly (sorry,
I lost my config.log). I even tried ITCL_LIBRARY="/usr/lib/itcl3.3" but it
didn't work. Fixed it by manually symlinking libitcl
$ ln -s /usr/lib/itcl3.3/libitcl3.3.so /usr/lib/libitcl3.3.so

'configure' then failed because it was using the tcl.h header from the brlcad
package instead of the one in /usr/include. The tcl.h in brlcad has added
#include "common.h" (which is a brlcad header) at line 19 and common.h has the
following at line 50: 
----------------------------------------
#  ifdef HAVE_CONFIG_H
#    include "brlcad_config.h"
#  else
#    include <brlcad/brlcad_config.h>
#  endif
----------------------------------------
I don't know why but it was using <brlcad/brlcad_config.h>, which doesn't exist
("brlcad.h" would work). Either way, configure should be checking against the
system tcl.h in /usr/include. The order of include dirs in the conftest program
was "-I/usr/X11R6/include -I$(top_srcdir)/include -Iinclude", which should find
/usr/include/tcl.h before brlcad/include/tcl.h but it wasn't. Anyway I changed
configure.ac to leave out the -Iinclude and that fixed that problem (see
attached brlcad-7.4.2-system-tcl.diff).

'configure' then failed due to lack of libitk symlink in /usr/lib. After
symlink added, brlcad compiled and merged successfully. I know the itcl3.3
ebuild by Michal Slonina in bugzilla had some symlinking in it, but this was
removed from the ebuild committed to portage by the itcl3.3 maintainer.

In summary, to get working
$echo 'TCL_LIBRARY="/usr/lib/tcl8.4"' > /etc/env.d/50tcl
$env-update; source /etc/profile
$emerge --onlydeps brlcad
$ln -s /usr/lib/itcl3.3/libitcl3.3.so /usr/lib/libitcl3.3.so
$ln -s /usr/lib/libitcl3.3.so /usr/lib/libitcl.so
$ln -s /usr/lib/itk3.3/libitk3.3.so /usr/lib/libitcl3.3.so
$ln -s /usr/lib/libitk3.3.so /usr/lib/libitk.so
$mv ~/brlcad-7.4.2-system-tcl.diff /usr/local/portage/sci-misc/brlcad/files
Add "epatch ${FILESDIR}/${PF}-system-tcl.diff" to brlcad-7.4.2.ebuild on the
line after "epatch ${FILESDIR}/${PF}-gentoo.diff"
$ebuild /usr/local/portage/sci-misc/brlcad/brlcad-7.4.2.ebuild digest
$emerge brlcad

Sorry for all the dodgy hacks but I'm not too knowledgeable in these areas.
There's also the chance that I was doing something wrong and I don't need to
symlink and patch, but I killed my config.log so I can't post it.

After setting my TCL_LIBRARY variable, and getting the test ebuild in overlay,
I
thought I might be good. I began running into some problems while .configure
was
running, unfortunately I didn't think to record the error messages as well as
the packages that they addressed. So far, I have had to install the following
packages in order to get the program to move forward with .configure: 

media-libs/urt
dev-lang/tcl
dev-lang/tk
devl-tcltk/itcl (which also brought in dev-tcltk/iwidgets). 

I of course had to setup the TCL_LIBRARY environmental setting. 

Now, I am getting stopped by incrTcl. It gives me the following info:
checking for Tk library functionality... yes
checking whether to build Tk... no
checking for incrTcl library functionality... no
configure: }}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}
configure: Try adding --enable-itcl-build
configure: error: *** incrTcl was disabled, yet no usable libitcl system
library
was found ***

!!! Please attach the config.log to your bug report:
!!! /var/tmp/portage/brlcad-7.4.2/work/brlcad-7.4.2/config.log

I will create an attachment with that config.log. 

Any suggestions how I can get past this? Is there any other information I can
provide you with that will help? 

Alas, I could not fine my config.log. The only one on the system seems to be
for
something I built by hand that wasn't in portage, and wasn't crucial enough to
request an ebuild. 

Incidentally, I found a link to the incrtcl project on sourceforge. Is this
perhaps something that will need an ebuild for this as well? 
http://incrtcl.sourceforge.net/

Created an attachment (id=70874) [details]
brlcad ebuild + diff + manifest + digest

Sorry if I am doing this wrong.  This is my first time.  I figured while I was
trying to get brl-cad working I might as well contribute to this.  

I updated the diff to include the necessary changes for 1.6.2.	I think I have
all my steps here.  I started by:

#echo 'TCL_LIBRARY="/usr/lib/tcl8.4"' > /etc/env.d/50tcl
#env-update; source /etc/profile
#emerge --onlydeps brlcad
#ln -s /usr/lib/itcl3.3/libitcl3.3.so /usr/lib/libitcl3.3.so
#ln -s /usr/lib/libitcl3.3.so /usr/lib/libitcl.so
#ln -s /usr/lib/itk3.3/libitk3.3.so /usr/lib/libitcl3.3.so
#ln -s /usr/lib/libitk3.3.so /usr/lib/libitk.so

Then I just did emerge brlcad with my ebuild and diff installed in local
overlay .  Everything seems to work and it is using the system libs.

I hope this is helpful to someone.

I take it the most recent ebuild is for 7.6.2 rather than 1.6.2?

I am still dubious about not building the support libraries as distributed 
with brlcad specifically for brlcad.  IIRC they have made changes specifically 
needed for brlcad that have not been rolled back into the support libraries - 
has this changed?  I fear we might get unpredictable failures if we go the way 
the current ebuilds are proposing.  Does anybody have an opinion from the 
brlcad developers on this issue?

Thanks to all that have been helping to get the Gentoo ebuild working.  The
efforts are very much 
appreciated.  While there is still more work that needs to be done both with
the ebuild itself as well as 
to BRL-CAD's build system, I'm glad to see the issues getting resolved so that
BRL-CAD may become a 
good citizen on the Gentoo platform.

There have been many comments to date, so I'll just point out a few
noteworthies.  1) Release 7.6.4 has 
just posted today which should resolve a few issues.  For example, the incrTcl
test using brl-cad's tcl.h 
instead of a system tcl.h issue should be fixed.  2) BRL-CAD's Tk extension
still utilizes canvas widget 
internal headers, even though it moved from libtk to libtclcad for the very
reason of linking against a 
system tcl/tk.  This particular issue is still being looked into to find a
workable solution.  3) Setting 
TCL_LIBRARY "shouldn't" be required unless libtcl is relocated.  There are
similar variables for Tk, Itcl, 
etc that rely on the compile-time paths unless relocated as well.  4)
Installing to /usr still won't 
necessarily/always work yet due to potential core library naming conflicts that
we cannot change (e.g. 
libbu, libbn, librt).  I am working on adding configuration build support to
install libraries into $prefix/
lib/brlcad or $prefix/lib/brlcad/VERSION similar to the shared resources so
that multiple versions may 
be installed as well as to avoid naming conflicts.  5) Anyone's thoughts on
these issues are always 
appreciated.

As for the various possible names of the project (i.e. BRL-CAD versus brlcad
versus BRLCAD versus brl-
cad etc) for systems that make a distinction between account names or short
names and full names, 
"BRL-CAD" is the preferred long/full name and brlcad is the conventional
short/file/dir name (for typing 
convenience mostly).  The "brl-cad" variant is fine for conversation and
developer notes and even 
preferred over "brlcad" in discussion but it shouldn't be used on anything
official; the other variants 
such as BRLCAD, BrlCAD, BrlCad, etc are discouraged.

Thanks again to everyone that has been contributing to the BRL-CAD ebuild and
for helping resolve 
configuration and build issues.

Almost got 7.6.4 to compile. I changed this in the 2005-10-17 ebuild
attachment:

myconf="${myconf} --enable-regexp-build=yes --enable-png-build=yes \
        --enable-zlib-build=yes --enable-urt-build=yes
--enable-termlib-build=yes \
        --enable-tcl-build=yes --enable-tk-build=yes --enable-itcl-build=yes
        --enable-iwidgets-build=yes"

I enabled all those and the errors during configure went away. But at the very
end of the long compile I got this sandbox collision:

/bin/install -c -m 644 ./describe.com.1 /usr/lib/describe.com
ACCESS DENIED  open_wr:   /usr/lib/describe.com
/bin/install: cannot create regular file `/usr/lib/describe.com': Permission
denied
make[4]: *** [install-data-local] Error 1
make[4]: Leaving directory
`/var/tmp/portage/brlcad-7.6.4/work/brlcad-7.6.4/src/other/jove'
make[3]: *** [install-am] Error 2
make[3]: Leaving directory
`/var/tmp/portage/brlcad-7.6.4/work/brlcad-7.6.4/src/other/jove'
make[2]: *** [install-recursive] Error 1
make[2]: Leaving directory
`/var/tmp/portage/brlcad-7.6.4/work/brlcad-7.6.4/src/other'
make[1]: *** [install-recursive] Error 1
make[1]: Leaving directory
`/var/tmp/portage/brlcad-7.6.4/work/brlcad-7.6.4/src'
make: *** [install-recursive] Error 1

!!! ERROR: sci-misc/brlcad-7.6.4 failed.


..not sure why I'm getting that error. That file doesn't already exist in
/usr/lib .

IIRC sandbox errors tend to happen when the install process tries to stick a 
file into the "real world" instead of respecting the variables that put it 
into the work directory.  I think what happens is the program goes through a 
complete install in the working directory, and then that install is copied to 
the system directories.  If someone knows better please correct me.

I think this is actually why so much scientific software is hard to write 
ebuilds for - a lot of the authors don't create proper configure - make - make 
install routines and just go straight for the absolute paths, which is a big 
no-no in the ebuild world.  brlcad of course is much better off, so I'm 
guessing this might just be a problem with a particular variable/file.

The real short answer is to add --diable-jove-build and it shouldn't have that
sandbox error.  The 
configure script will enable jove's compilation by default if it doesn't find
an installed jove, but having it 
enabled or disabled isn't critical.  Especially since jove is in portage
separately, it should probably be 
disabled explicitly regardless or made a dependency of the package.

That said, there is a sandbox error in jove's Makefile.am where a DESTDIR is
missing similar to what we 
ran into earlier with other components of the package a while back.  There are
a couple files in jove that 
have custom install rules that only installed to the configure'd install path. 
I'll add a fix for DESTDIR to 
keep our sand in the box, should be in the 7.6.6 that's going up probably this
weekend.

Once the new version is out this weekend we will test it out in an overlay. I  
would like to get this added to portage and work out the rest of the kinks. I 
don't think there are any major issues standing in the way now.  

We have been working to get brlcad in the sci overlay. However, we can not make
it build. 

A new patch for configure.ac has been made because the provided one has many
flaws, like, for example, the tk test fails if DISPLAY is not set, which is not
acceptable.

The patch is far from perfect. It replaces the tcl/tk/itcl/iwidgets tests. The
tcl and tk are mostly ok, itcl is not so good and the iwidgets test has been
removed for now.

Besides, with the patch applied, it fails to compile:

i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I../../../include  
-I/usr/X11R6/include -I../../../include  -O2 -march=athlon-xp
-fomit-frame-pointer -pipe -fno-strict-aliasing -fno-common -c jove_buf.c
In file included from jove_buf.c:64:
./jove.h:256: warning: built-in function 'exp' declared as non-function
./jove.h:477: error: conflicting types for 'malloc'
./jove.h:477: error: conflicting types for 'malloc'
make[4]: *** [jove_buf.o] Error 1

Please find attached the new ebuild for 7.6.6, based on the latest ebuild from
this bug, the patch and tcl.m4 which should be copied to the files directory.

Lucas Chiesa

Created an attachment (id=78208) [details]
New ebuild

(From update of attachment 78208 [details])
New ebuild for 7.6.6

Created an attachment (id=78209) [details]
brlcad-7.6.6-gentoo.diff

New patch for configure.ac

Created an attachment (id=78210) [details]
tcl.m4

This m4 file is used by the patched configure.ac. It should be copied to files/

Created an attachment (id=79973) [details]
the emerge log file

Hello all!
I'm searching for a good CAD-Programm like Proe etc. i thought brlcad could be
a good choice. so i decided to get the ebuild. but my gentoo wont install all
aof the above versions. the emerge messege is the following when i try to
emerge the 7.6.6 version

 files/brlcad-7.6.2-gentoo.diff
>>> md5 files   ;-) files/brlcad-7.6.6-gentoo.diff
>>> md5 files   ;-) files/digest-brlcad-7.6.6
>>> md5 files   ;-) files/digest-brlcad-7.6.2
>>> md5 files   ;-) files/tcl.m4
>>> md5 src_uri ;-) brlcad-7.6.6.tar.bz2
>>> Unpacking source...
>>> Unpacking brlcad-7.6.6.tar.bz2 to /var/tmp/portage/brlcad-7.6.6/work
 * Applying brlcad-7.6.6-gentoo.diff ...                                       
                                             [ ok ]

!!! ERROR: app-cad/brlcad-7.6.6 failed.
!!! Function econf, Line 498, Exitcode 1
!!! no configure script found
also i tried the hint: echo >/etc/env.d/50tcl TCL_LIBRARY="/usr/lib/tcl8.4" but
no luck!
i tried much but im not so famillar with gentoo yet.
my system: amd barton 2500+, asus a7n8x-deluxe (nforce2), gf4 gpu, 1gb ram.

main things what i've installed: kde3.4, xorg, kernel 2.6.12-gentoo-r6
my make.conf:
# These settings were set by the catalyst build script that automatically built
this stage
# Please consult /etc/make.conf.example for a more detailed example
CFLAGS="-O3 -march=athlon-xp -fforce-addr -momit-leaf-frame-pointer
-fomit-frame-pointer -ftracer -pipe"
#CFLAGS="-O2 -march=athlon-xp -fomit-frame-pointer -pipe"
CHOST="i686-pc-linux-gnu"
CXXFLAGS="${CFLAGS} -fvisibility-inlines-hidden"
#CXXFLAGS="${CFLAGS}"
ACCEPT_KEYWORDS="x86"
PORTAGE_TMPDIR="/var/tmp"
PORDIR="/usr/portage"
DISTDIR="/distfiles"
PKGDIR="$/distfiles"
PORT_LOGDIR="/var/log/portage"
PORTDIR_OVERLAY="/usr/local/portage"
#GENTOO_MIRRORS="http://gentoo.osuosl.org"
GENTOO_MIRRORS="http://gentoo.eliteitminds.com
http://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/
ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/
http://pandemonium.tiscali.de/pub/gentoo/"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
RSYNC_RETRIES="3"
RSYNC_TIMEOUT="30"
MAKEOPTS="-j2"
PORTAGE_NICENESS="3"
AUTOCLEAN="yes"
FEATURES="ccache distlocks sandbox userpriv usersandbox"
CCACHE_SIZE="2G"
RSYNC_EXCLUDEFROM="/etc/portage/rsync_excludes"
LINGUAS="de"
ALSA_CARDS="intel8x0"
USE="-apm nptl jack jack-tmpfs oss alsa kde qt sse mmx 3dnow opengl X -gtk
-gnome artswrappersuid audiofile avi cdr cups cpdflib curl crypt directfb doc
dvd dvdr encode fastcgi flac flash ftp jpeg mpeg memlimit portaudio posix sdl
samba scanner shared sharedmem theora truetype tiff usb video wmf wxwindows
xine xinerama xmms xv xml2"

if ive missing something im very sry!
anyway thx for time and help!

Created an attachment (id=82390) [details]
fixed spelling errors and added enable-jove=no

Created an attachment (id=82391) [details]
config.log for failed build

There are two spelling errors in the current ebuild: 

"autoconf" should be replaced by "eautoconf. it's the reason why this doesn't
build for you GENTOO ROCKS. 

"enable-regexp-build=no" should be replaced with "enable-regex-build=no"

And also '--enable-jove=no' could be added to the configure section afaik.
Because jove is also in portage.

See the new ebuild I put up here.

But in the end, brlcad fails to build for me as well:

[snip]
/bin/sh ../../libtool --mode=link i686-pc-linux-gnu-gcc  -mtune=athlon-xp -O3
-pipe -fomit-frame-pointer -funroll-loops -mmmx -msse -ffast-math
-frerun-cse-after-loop -pipe -fno-strict-aliasing -fno-common -O3 
-L/usr/X11R6/lib -L/usr/local/lib -pipe -fno-strict-aliasing -fno-common -O3 -o
comb  comb.o librt.la ../../src/libbu/libbu.la
i686-pc-linux-gnu-gcc -mtune=athlon-xp -O3 -pipe -fomit-frame-pointer
-funroll-loops -mmmx -msse -ffast-math -frerun-cse-after-loop -pipe
-fno-strict-aliasing -fno-common -O3 -pipe -fno-strict-aliasing -fno-common -O3
-o .libs/comb comb.o  -L/usr/X11R6/lib -L/usr/local/lib ./.libs/librt.so
/var/tmp/portage/brlcad-7.6.6/work/brlcad-7.6.6/src/libbn/.libs/libbn.so
/var/tmp/portage/brlcad-7.6.6/work/brlcad-7.6.6/src/libbu/.libs/libbu.so -lm
../../src/libbu/.libs/libbu.so -lc -lpthread
./.libs/librt.so: undefined reference to `Tcl_CreateFileHandler'
./.libs/librt.so: undefined reference to `Tcl_GetStringResult'
./.libs/librt.so: undefined reference to `Tcl_GetCharLength'
./.libs/librt.so: undefined reference to `Tcl_ListObjGetElements'
./.libs/librt.so: undefined reference to `Tcl_GetDoubleFromObj'
./.libs/librt.so: undefined reference to `Tcl_GetBooleanFromObj'
./.libs/librt.so: undefined reference to `Tcl_ListObjLength'
./.libs/librt.so: undefined reference to `Tcl_ListObjAppendList'
./.libs/librt.so: undefined reference to `Tcl_PkgProvide'
./.libs/librt.so: undefined reference to `Tcl_GetStringFromObj'
./.libs/librt.so: undefined reference to `Tcl_DeleteFileHandler'
./.libs/librt.so: undefined reference to `Tcl_DoOneEvent'
./.libs/librt.so: undefined reference to `Tcl_AppendElement'
[snip] and so on....

I have these tcl related packages:
dev-tcltk/itcl-3.3-r1
dev-tcltk/tcllib-1.7
dev-lang/tcl-8.4.12

Also, see the config.log I posted.

TCL_LIBRARY variable is set. Anybody knows what could be the problem?

Created an attachment (id=89873) [details]
Primative ebuild for 7.8.2

This is not an ideal ebuild in that it uses all the internal brl-cad versions
of libraries, but it should produce a working brl-cad at least.  jove has a
makefile bug that causes a sandbox violation, which is the only reason it is
disabled.  The upstream maintainer says this probably isn't worth patching for
since jove is just an editor that brl-cad has provided for ~forever...

Anyway - again, not a good ebuild - it's basically a hack and slashed version
of the 7.6.6 ebuild.  It's only merit is that it was able to produce a gentoo
compiled and installed brl-cad on my machine.

Cheers,
CY

Crud - it looks like the above ebuild still overwrites librt and a couple other
files in the lib directory that could cause trouble.  It will get you a working
brlcad, but may do odd things to your system - Beware!

Created an attachment (id=109012) [details]
revdep_rebuild report of damage

As a warning/guide, I've attached revdep-rebuild's report of the carnage that
was visited on my system (if history is a guide, only a complete reinstall fill
fix this :-( ).  I don't know if this is the ebuild or if I did it myself
outside of the system, as I don't think I had the sandbox disabled...

now, 7.10.0 is out

let's work out an ebuild for it, also, an ebuild for -cvs

Sounds good, but watch out - I've re-installed my system twice after brl-cad
ebuild attempts nuked key libraries beyond even revdep-rebuild's ability to
repair.  brlcad includes similar libraries to standard installs, but tweaked
for brlcad support.  I'm not clear if we can avoid installing them (i.e. if the
standard libraries can work) but if not keeping them from conflicting with the
"main" system libraries is critical.

My damage report above shows what happened with a gone wrong ebuild attempt, so
I'd suggest developing on a test machine if you can.

(In reply to comment #62)
> Created an attachment (id=109012) [edit] [details]
> revdep_rebuild report of damage

---------------------------------------------------

add --prefix=/usr/brlcad/ , instead of --prefix=/usr/

to make revdep-rebuild work, run

revdep-rebuild -p
for p0 in $(cat /root/.revdep-rebuild.5_order); do echo $p0;emerge -C
=$p0;emerge -1 =$p0;done
emerge -uDN world

Created an attachment (id=116773) [details]
ebuilds for 7.10.0 and cvs

the 7.10.0 should build.

the cvs ebuild got problem at checkout, but rerun "emerge brlcad" should work
at updating mode.

those ebuilds won't mess up your system, because everything is installed under
/usr/brlcad/

finally, /usr/brlcad/bin/mged to launch

I hope some gurus would make some good ebuilds for us still

Created an attachment (id=118511) [details]
updated 7.10.0 ebuild

build brlcad-7.10.0 with system regexp, libz, and libpng (if available)

Created an attachment (id=118543) [details]
brlcad-0.7.10.ebuild and brlcad-9999.ebuild

both 7.10.0 and -cvs work for me

read postinst info for ENVs needed to launch mged

Further improvements made to the BRL-CAD system have gotten it to the point
where I think we should look at finalizing an ebuild.  Here's the current
situation as far as I know it:

By default, the autoconf scripts will check existing versions of system
libraries for versions they need.  If a workable version is found, it will use
it.  If not, it will fall back on the included version.

I think the way to handle this is for BRL-CAD to include as DEPENDS every
library which MIGHT be used from the system.  This will mean that Gentoo will
install the latest available version of each library, and BRL-CAD will test
those versions to see if they meet requirements.  If they do, well and good. 
If not, BRL-CAD itself will know to fall back onto internal libraries.  Once
the libraries on the system are fully capable, a rebuild of BRL-CAD will result
in the "correct" behavior for building and (re)installing.  As there are likely
to be times where the required versions of libraries will run ahead of
"standard" versions in Gentoo (for example, TCL 8.5 is required by 7.10.2) I
think this behavior is needed and desirable.

Second, the target directory for install.  The default is /usr/brlcad. There
are good reasons for keeping BRL-CAD isolated from the primary lib directories,
the main one being some of its libraries will conflict with standard system
libraries.  OpenDX seems to do something similar so such a configuration would
not be without precedent.

Currently the TCL needed for the system does require a version of the tcl patch
for documentation paths - the Makefiles that need patching aren't present
before the configure step so the choices are either to track the problem all
the way back to its source or apply an epatch after the configure step is run. 
The latter seems to be simpler at the moment (it avoids the need to re-run
autoconf, for one) although the patch for 7.10.0 doesn't seem to work by
default - a new one will need to be made up.

The 7.10.2 ebuild is a test configuration, which needs the new tcl/tk makefiles
patch to be generated.  The sed logic in src_install is left in for the moment,
although I need to better understand why it is there.

I'm not sure if mged should be symlinked into /usr/bin or not - mged is what
most new users of BRL-CAD would start up.

I'm not sure why ADRT support isn't being enabled.  Currently, this is the
build config that results from BRL-CAD probing the system:

USE="ef optimize pic proengineer ug" emerge brlcad

BRL-CAD Release 7.10.2, Build 20070910

             Prefix: /usr/brlcad/
           Binaries: /usr/brlcad//bin
       Manual pages: /usr/share/man
Configuration files: /etc
Data resource files: /usr/share
Options & variables: --prefix=/usr --host=i686-pc-linux-gnu
--mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share
--sysconfdir=/etc --localstatedir=/var/lib --prefix=/usr/brlcad/
--enable-pro-engineer-plugin --with-jdk=/opt/sun-jdk-1.5.0.12 --with-pic
--disable-debug --enable-ef-build --enable-ug-build --enable-optimized
--enable-runtime-debug --build=i686-pc-linux-gnu

CC       = i686-pc-linux-gnu-gcc
CXX      = i686-pc-linux-gnu-g++
CFLAGS   = -O2 -march=i686 -pipe -pipe -fno-strict-aliasing -fno-common -O3
CXXFLAGS = -O2 -march=i686 -pipe -pipe -fno-strict-aliasing -fno-common -O3
CPPFLAGS = -DBRLCADBUILD=1 -I${top_srcdir}/include
LDFLAGS  = -L/usr/local/lib -pipe -fno-strict-aliasing -fno-common -O3

Build Tcl ............................: yes
Build Tk .............................: yes
Build Itcl/Itk .......................: yes
Build IWidgets .......................: yes
Build BLT ............................: yes
Build tkImg ..........................: yes
Build libpng .........................: no (using system)
Build libregex .......................: no (using system)
Build zlib ...........................: no (using system)
Build termlib ........................: no (using system)
Build Utah Raster Toolkit.............: no (using system)
Build Template Numerical Toolkit......: yes
Build openNURBS.......................: no (doing without, BREP unsupported)
Build jove ...........................: no

ADRT support .........................: no (need python and sdl)
X11 support ..........................: yes
OpenGL support .......................: yes
Java Developer Kit support ...........: yes (/opt/sun-jdk-1.5.0.12)
Enable run-time debugging ............: yes

Build 64-bit release .................: no (32-bit)
Build optimized release ..............: yes
Build debug release ..................: no
Build profile release ................: no
Build static libraries ...............: yes
Build shared/dynamic libraries .......: yes
Print verbose compilation warnings ...: no
Print verbose compilation progress ...: no

Only build benchmark suite ...........: no
Only build librtserver ...............: no
Install example geometry models ......: yes

Elapsed configuration time ...........: 1 minute, 34 seconds
---
./configure complete, type 'make' to begin building

Created an attachment (id=130670) [details]
brlcad-7.10.2 ebuild

Need to generate a new tcl-doc.diff patch for 7.10.2 before this ebuild will
work.  It attempts to add all the USE flags that would be appropriate for this
use.

Thanks again to all the folks working hard on the ebuild, particularly to
Cliff.  I'm pretty excited to hear about the progress being made.  We've
certainly put a lot of effort into making our build more flexible to the
various packaging systems (e.g., decoupling/rewriting what were custom tk mods)
including working out details for portage.  We still have a few naming
conflicts that prevent a /usr prefix (particularly for our libraries) but the
package should integrate a lot better now with respect to the Tcl/Tk problems
we had earlier on.

A few comments about Cliff's recent comments and build settings, if I may.  I
would also recommend letting BRL-CAD's auto-detection do its thing and not
forcibly enabling/disabling dependency options.  If the deps that are tied to
the ebuild are installed, then they will be detected during configure and just
get used.  If not, the build can (and would) still complete since we include a
version of every required dep.

As for the build settings, there are a few components that really don't need to
be enabled and probably shouldn't be enabled including the Endgame Framework,
Pro/Engineer, and Unigraphics/NX modules.  Those packages all required external
(proprietary) developer kits in order for them to compile, not something the
vast majority on Gentoo will likely ever have installed.

The Java interface is similarly not used by any of our tools, it's an interface
used by 3rd-party developers that hook to our libraries via a jnilib.  It
should just be disabled (and Java should NOT be a required BRL-CAD dependency).

Also, ADRT does not need to be manually enabled or disabled, and is not a
concern that it shows up disabled.  It's a module that hasn't been
fully/properly integrated  yet, so the build system has it forcibly disabled in
7.10.2; and similar to Java, neither SDL or Python should be listed as required
BRL-CAD dependencies.  From your list of flags, something like the following
would be suggested:

--mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share
--sysconfdir=/etc --localstatedir=/var/lib --prefix=/usr/brlcad/
--with-pic
--enable-optimized
--build=i686-pc-linux-gnu

Cheers!
Sean

> A few comments about Cliff's recent comments and build settings, if I may.
> I would also recommend letting BRL-CAD's auto-detection do its thing and
> not forcibly enabling/disabling dependency options.  If the deps that are
> tied to the ebuild are installed, then they will be detected during
> configure and just get used.  If not, the build can (and would) still
> complete since we include a version of every required dep.

Hmm.  Two concerns about such an approach.  I had originally thought to add the
dependencies as a concession to the view that BRL-CAD should use system
libraries in preference to its own internal copies whenever possible.  This
would make sure that whatever the latest copies available on a given version of
Gentoo are, they are installed for configure to try.  The second reason and
possibly more important (although I admit it occurs to me after the fact) is
that if BRL-CAD detects and uses a system library that is not listed in its
ebuild requirements, there is a chance (a remote one, but a chance) that a
library would be removed or updated without the Gentoo system being aware its
removal (or update) would cripple BRL-CAD.  A re-emerge of BRL-CAD would fix
the issue however (switching to the internal library version), so perhaps it is
not so critical - Gentoo gurus, is there anything about the current emerge
system that would be made unhappy in this situation if system libraries in use
are not listed as DEPENDS in the ebuild?

> As for the build settings, there are a few components that really don't
> need to be enabled and probably shouldn't be enabled including the Endgame
> Framework, Pro/Engineer, and Unigraphics/NX modules.  Those packages all
> required external (proprietary) developer kits in order for them to compile,
> not something the vast majority on Gentoo will likely ever have installed.

OK - those flags can be removed, obviously :-).  I was just trying to cover all
the likely options based on the INSTALL file.  I don't guess those proprietary
kits would get used on Gentoo with ebuilds, and if the issue does come up it is
simple enough to add them back in.

> The Java interface is similarly not used by any of our tools, it's an
> interface used by 3rd-party developers that hook to our libraries via a
> jnilib.  It should just be disabled (and Java should NOT be a required
> BRL-CAD dependency).

Sounds good.

> Also, ADRT does not need to be manually enabled or disabled, and is not
> a concern that it shows up disabled.  It's a module that hasn't been
> fully/properly integrated  yet, so the build system has it forcibly
> disabled in 7.10.2; and similar to Java, neither SDL or Python should be
> listed as required BRL-CAD dependencies.

OK, sounds good.  It's nice when things get simpler ;-).

> From your list of flags, something like the following would be suggested:
> --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share
> --sysconfdir=/etc --localstatedir=/var/lib --prefix=/usr/brlcad/
> --with-pic --enable-optimized --build=i686-pc-linux-gnu

Looks good - thanks!  In this situation (ebuild for workstation install) would
you suggest enabling optimized in all cases?  As for the --build option, I'll
need to look into that - it would have to be conditionalized somehow for each
arch.  I don't suppose configure can autodetect it?

Cheers, and thanks!
Cliff

(In reply to comment #72)
> Hmm.  Two concerns about such an approach.  I had originally thought to add the
> dependencies as a concession to the view that BRL-CAD should use system
> libraries in preference to its own internal copies whenever possible.  This
> would make sure that whatever the latest copies available on a given version of
> Gentoo are, they are installed for configure to try.  The second reason and
> possibly more important (although I admit it occurs to me after the fact) is
> that if BRL-CAD detects and uses a system library that is not listed in its
> ebuild requirements, there is a chance (a remote one, but a chance) that a
> library would be removed or updated without the Gentoo system being aware its
> removal (or update) would cripple BRL-CAD.  A re-emerge of BRL-CAD would fix
> the issue however (switching to the internal library version), so perhaps it is
> not so critical - Gentoo gurus, is there anything about the current emerge
> system that would be made unhappy in this situation if system libraries in use
> are not listed as DEPENDS in the ebuild?

I would consider that latter case a "bug" in the ebuild.  I.e. if BRL-CAD were
dependent upon some unlisted package, the problem really is just that it's not
listed and needs to be.  List the proper dependencies and the problem is
solved.  I agree that it should just use system libraries and specifically have
each one of those listed that is used.  If someone tries to remove a required
dependency, it'll show up as required by BRL-CAD.

> OK - those flags can be removed, obviously :-).  I was just trying to cover all
> the likely options based on the INSTALL file.  I don't guess those proprietary
> kits would get used on Gentoo with ebuilds, and if the issue does come up it is
> simple enough to add them back in.

At $10k-$20k USD per license, the market for those developer kits is
excessively small and pretty much limited to folks that have a pretty good
handle on what to do with getting those kits to work with BRL-CAD.  We're
talking about a small number of folks that can probably be counted on one hand.

> Looks good - thanks!  In this situation (ebuild for workstation install) would
> you suggest enabling optimized in all cases?  As for the --build option, I'll
> need to look into that - it would have to be conditionalized somehow for each
> arch.  I don't suppose configure can autodetect it?

The --build option was probably auto-added by portage; my options list was
based off of the summary that you posted earlier.  There are probably a lot of
other options that are being auto-added that I listed that you do not want to
manually list.

As for optimized builds, probably.  I can't think of a good reason at the
moment why you wouldn't want to leave that option off other than to use
cflags/cxxflags instead of enable-optimized, using optimization settings coming
directly from portage that the user had set.  I'm not familiar with how that
comes into play on gentoo, whether user-provided optimization settings merely
are appended so they override, or if there are separate option sets.  Either
way should work just fine.

Cheers!
Sean

> I would consider that latter case a "bug" in the ebuild.  I.e. if BRL-CAD
> were dependent upon some unlisted package, the problem really is just that
> it's not listed and needs to be.  List the proper dependencies and the
> problem is solved.  I agree that it should just use system libraries and
> specifically have each one of those listed that is used.  If someone tries
> to remove a required dependency, it'll show up as required by BRL-CAD.

Right.  Sorry, I think I mis-read your comment initially - it sounds like we're
on the same page.

> The --build option was probably auto-added by portage; my options list was
> based off of the summary that you posted earlier.  There are probably a lot
> of other options that are being auto-added that I listed that you do not
> want to manually list.

Ah, right.  I'll review a couple other ebuilds, but I think you spotted the key
flags.

> As for optimized builds, probably.  I can't think of a good reason at the
> moment why you wouldn't want to leave that option off other than to use
> cflags/cxxflags instead of enable-optimized, using optimization settings
> coming directly from portage that the user had set.  I'm not familiar with
> how that comes into play on gentoo, whether user-provided optimization
> settings merely are appended so they override, or if there are separate
> option sets.  Either way should work just fine.

Hmm.  Well, I would expect portage to use its default settings in make.conf
unless specifically overridden, and my guess is that they are appended.  I can
try running benchmarks on ebuild and manual builds to see if there is a
difference, but I doubt it is too important.  I think you can override settings
on a per-emerge command basis (I know this can be done for the USE flag) so I
doubt there will be any trouble.

OK, time to get busy.  With any luck I will have some time this weekend to pull
something fully functional and conforming to the ebuild guidelines together,
and then we can start bugging the portage gods to include it ;-).

Cheers,
CY

OK, after some weekend hacking there is now what should be working and "proper"
7.10.2 ebuild.  The fix from dongxu li is included - there was a slight change
to the tk makefile evidently between 7.10.0 and 7.10.2, but correcting for that
it still seems to do what is intended.  For some reason I can't quite get a
single patch file for everything to do its thing, so I've got one for tcl and
one for tk.  I doubt it matters much but if someone wants to combine them it
shouldn't change anything.

The install target is now /opt/brlcad, which is closer to "proper" practice
than /usr/brlcad.  As reading over the bug history will show this has been
hashed out before, but I think /opt is emerging as the most desirable option. 
There are at least three libraries in BRL-CAD which have name conflicts with
standard libraries - not included versions of system installed libraries but
truly different libraries.  These can't be renamed because there are
compatibilities that must be maintained, so the only viable options appear to
be either /opt/brlcad/ or coming up with some sort of /usr/lib/brlcad/
arrangement.  So far /opt appears to work just fine in my testing - normally
opt is reserved for binary installations but it seems like a good match for
this situation as well.
The earlier observation that BRL-CAD didn't need any duplicate libraries isn't
true currently unless (at a minimum) tcl/tk-8.5 is unmasked, and there is no
guarantee in the future that available system libraries on a given Gentoo box
can be made to work.  /opt avoids all of the potential problems.

An env.d file containing the PATH and MANDIR settings for BRL-CAD is also
included in the files directory.  This file will be installed into /etc/env.d
and once env-update && source /etc/profile are run will result in mged and
friends being in the path by default.  There is also a license file to be added
for the documentation - BLD.

I've run repoman over the ebuild and gone over all the ebuild writing policy I
can find.  To the best of my knowledge, BRL-CAD is now ready for inclusion in
portage.

Thanks to Sean and his team, who did all the really hard work to make this
possible, and to the army of ebuild writers who have tackled this!  Now we need
to find out of there is a developer who is willing to sponsor this in the main
portage tree itself.

Cheers,
CY

Created an attachment (id=131083) [details]
Updated BRL-CAD ebuild

This version installs to /opt/brlcad, including the env.d settings needed.

Created an attachment (id=131085) [details]
tcl patch

Patch for tcl makefile per earlier 7.10.0 patch

Created an attachment (id=131087) [details]
tk patch

tk Makefile patch

Created an attachment (id=131089) [details]
env.d file for /opt/brlcad paths

Installed by ebuild in /etc/env.d

Created an attachment (id=131091) [details]
BDL documentation license

This is the BRL-CAD documentation license, which doesn't seem to be in portage.
 I currently have it in /usr/local/portage/licenses

Created an attachment (id=131094) [details]
Convenient bundle of brl-cad files (except BDL license)

The previous files are submitted in order to comply with policy.  If anyone
wants a shortcut, this tarball contains everything except the BDL license file
(which needs to go elsewhere after all.)  This file also has a ChangeLog and
metadata.xml included in case that's of any help to the gentoo dev(s).  I use
this by making sure that:

a)  /usr/local/portage is an overlay in make.conf (there are docs on overlays)
b)  make sure /usr/local/portage exists in the filesystem
c)  mkdir /usr/local/portage/licenses
d)  place the BDL file in /usr/local/portage/licenses
e)  mkdir /usr/local/portage/sci-misc
f)  place the above tar file in /usr/local/portage/sci-misc
g)  tar -xvzf brlcad-7.10.2-ebuild.tar.gz

The last step should expand to a brlcad directory with the necessary contents. 
After that, it should work as expected.

Feedback appreciated.

Cheers,
CY

It compiles and loads fine here on x86 (athlon), except if profile USE flag is
set when it failed:

checking if compiler and linker recognize -pg... no
configure: }}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}
configure: Profiling was enabled but -pg does not work
configure: error: *** Don't know how to profile with this compiler ***

I imagine that's an ICC option?
I haven't tried loading any files (I don't know this package at all) but mged
ran without complaint, no warnings or anything to console.

Well done for getting there in the end :-)

(In reply to comment #82)
> It compiles and loads fine here on x86 (athlon), except if profile USE flag is
> set when it failed:
> 
> checking if compiler and linker recognize -pg... no
> configure: }}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}
> configure: Profiling was enabled but -pg does not work
> configure: error: *** Don't know how to profile with this compiler ***
> 
> I imagine that's an ICC option?
> I haven't tried loading any files (I don't know this package at all) but mged
> ran without complaint, no warnings or anything to console.
> 
> Well done for getting there in the end :-)

Steve, I've just added a check for icc's -p option (which adds gprof
instrumentation) to the latest sources so it'll be in subsequent releases.

The reason it wasn't already in there, though, is because ICC's best profile
instrumentation uses their multiphased build-run-rebuild passes (using
-prof_gen, -prof_use, and family).  That's a bit "too much" to hook into
configure given how frequently that compiler is used for that purpose, so I've
just added the flags by hand as needed.  So now, though, with -p added, it'll
work with gprof, but it's not going to give the nice performance tuned binaries
you might be looking for.

Cheers!
Sean

OK, one more tweak - it was suggested that it would be better to patch the
Makefile.in files rather than the Makefiles.  The updates to the ebuild and
patch files do this, and it has built successfully on my machine - ebuild runs
the autogen.sh script.

Created an attachment (id=131177) [details]
patch for tcl/tk makefiles

Used proper ebuild patch-building procedure, one file now.

Created an attachment (id=131178) [details]
brlcad-7.10.2.ebuild (patches correct files now)

Correct patch options, cut profile flag for now.

Created an attachment (id=131180) [details]
Convenient bundle of brl-cad files (except BDL license) [updated]

Update of earlier tarball.

Created an attachment (id=131182) [details]
Convenient bundle of brl-cad files (except BDL license) [updated]

Oops (obsolete older tarball(s) to avoid confusion)

Created an attachment (id=131183) [details]
brlcad-7.10.2-ebuild tarball

Sigh.  And put in correct file type (sorry for the spam)

(In reply to comment #89)
> Created an attachment (id=131183) [edit] [details]
> brlcad-7.10.2-ebuild tarball

wtf is this?

from the ebuild:

        insinto /etc/env.d
        newenvd "${FILESDIR}"/brlcad.envd 99brlcad

that insinto doesn't do anything I think. And why not name the file 99brlcad in
the first place?

The tarball is simply a convenience bundle of the files I had in
/usr/local/portage/sci-misc/brlcad for anyone who wanted to try it - it's
easier than grabbing everything one by one and placing them by hand.

As for the env.d - I think that command is a leftover before I used the newenvd
command, so it can go.  The filename itself - does it matter?  IIRC I was using
the same conventions for that as I saw in other ebuilds in portage.

Created an attachment (id=134457) [details]
Version update to latest, remove unneeded line

Shouldn't 
"       einfo "To run an example, try /opt/brlcad/bin /opt/brlcad/db/havoc.g"
read

"/opt/bclad/bin/mged /opt/brlcad/db/havoc.g" ?

The 'mged' is missing after the /bin .


Anyone know how well, or if brlcad will work on a AMD64 box?

I got this when I tried:

/opt/brlcad/bin/mged /opt/brlcad/db/havoc.g
Initializing and backgrounding, please wait...Itcl_Init error Can't find a
usable itcl.tcl in the following directories:
    /opt/brlcad/lib/itcl3.3 ./../lib/itcl3.3 ./../library ./../../library
./../../itcl/library ./../../../itcl/library ./../../../../itcl/library
./../../../../../itcl/library ./src/other/incrTcl/itcl/library
./../src/other/incrTcl/itcl/library ./../../src/other/incrTcl/itcl/library
./../../../src/other/incrTcl/itcl/library
./../../../../src/other/incrTcl/itcl/library
./../../../../../src/other/incrTcl/itcl/library
This probably means that Itcl/Tcl weren't installed properly.
If you know where the Itcl library directory was installed,
you can set the environment variable ITCL_LIBRARY to point
to the library directory.

Can't find a usable itk.tcl in the following directories:
    /opt/brlcad/lib/itk3.3 ./../lib/itk3.3 ./../library ./../../library
./../../itk/library ./../../../itk/library ./../../../../itk/library
./../../../../../itk/library ./src/other/incrTcl/itk/library
./../src/other/incrTcl/itk/library ./../../src/other/incrTcl/itk/library
./../../../src/other/incrTcl/itk/library
./../../../../src/other/incrTcl/itk/library
./../../../../../src/other/incrTcl/itk/library
This probably means that Itcl/Itk weren't installed properly.
If you know where the Itk library directory was installed,
you can set the environment variable ITK_LIBRARY to point
to the library directory.

MGED Aborted.
Done

brlcad does seem to work in 32bit chroot.

Good catch - it is indeed mged.

Not sure about AMD64 - that's not a platform I have available to test on :-(.

Created an attachment (id=134602) [details]
7.10.4 - Fix the info message to actually specify the mged binary

(In reply to comment #94)

> MGED Aborted.
> Done
> 
> brlcad does seem to work in 32bit chroot.

Request from upstream - would it be possible to provide a configure and build
log as well as the config.log file?  As attachments to the bug here is fine.

(In reply to comment #95)
> Good catch - it is indeed mged.
> 
> Not sure about AMD64 - that's not a platform I have available to test on :-(.

From my testing it looks like what needs done is that /opt/brlcad/lib64
needs added to the lib path, as it is not there now.

Specifying the libraries manually brings mged up:

~ $ ITK_LIBRARY=/opt/brlcad/lib64/itk3.3 ITCL_LIBRARY=/opt/brlcad/lib64/itcl3.3
/opt/brlcad/bin/mged /opt/brlcad/db/havoc.g
Initializing and backgrounding, please wait...Opened in READ ONLY mode
Done

Created an attachment (id=134848) [details]
configuration log for build on AMD64

configuration log for build on AMD64.

Created an attachment (id=134849) [details]
emerge --info for build on AMD64

emerge --info for build on AMD64

I have been able to build and work with brlcad within amd64. Not much though.
But if specific test are required I'm willing to play guinea pig - just drop me
a line.

The missing itcl/itk paths did I solve by creating symbolic links in
/opt/brlcad/lib/itcl3.3 to /opt/brlcad/lib64/itcl3.3 and itk3.3 respectively.

Created an attachment (id=136002) [details]
Updated BRL-CAD ebuild

In the ongoing effort to make an inclusion-worthy ebuild, here is the latest
effort.  Thanks to Sébastien Fabbro for much helpful advice.

New points:

1. Install is now done in /usr/$(get_libdir)/brlcad instead of /opt, in order
to comply with the "binary only" designation for the /opt directory.

2.  Removed tcl/tk depends, which are covered by itcl/itk.  Added blt.  

3.  Switched from pre-existing 99brlcad file to one created by the ebuild
process itself, in order to ensure the correct $(get_libdir) value.

4.  Further consolidated ebuild flags - I'm not sure if this is TOO far but
this should be correct for "normal" operation and Sébastien's thought was that
people wanting large scale customization would be likely to build their own
copy outside portage.

5.  Additional use of the $(get_libdir) variable in the configure setup - this
MAY fix the issues seen with the lib64 directory paths on AMD64, but I'm not
completely sure - testing definitely appreciated.

Things not yet changed:

1.  Still calling BRL-CAD's own autogen.sh script - eautoreconf doesn't seem to
work when I tried it.  (Noted in the comments.)  Running autoconf is motivated
by patching the Makefile.in file rather than the Makefile directly (per earlier
comments) - that's the "correct" way to do it.  It may be possible to patch
both if running the autogen.sh script is a major problem, but considering how
long the BRL-CAD build is anyway I personally think this is acceptable.

2.  BRL-CAD in this version will still build mostly internal libraries.  The
cvs  tree of BRL-CAD has some logic to check for 8.4 and friends and use those
if available, but the 7.10.4 tarball would need patching.  Some of these
libraries (tkimg is one example) do not yet have ebuilds in the main tree, so
attempting to correct this wholesale would involve the from-scratch creation of
several ebuilds and approval of anywhere from two to four+ for inclusion in the
main tree at the same time as BRL-CAD itself.  My take on this is to allow the
process to be a gradual one - as more libraries are added to the tree and new
BRL-CAD releases appear, the need for internal lib building will gradually fall
away without any real fuss.  I know this is a hot button topic, but if this and
the previous issue are the last two major ones standing in the way of this
being adopted we must either begin the large scale ebuild process or reach a
decision to go ahead and gradually wean the build off of internal libs.

There may still be a couple minor style points - I'm not sure I've gotten
everything to the last detail, but I'd like the AMD64 guys (if willing) to give
this a try and see if it works out of the box for them.

CY

Still not working out of the box on AMD64.

There is no such thing as /usr/lib64/brlcad/lib/itcl3.3 .
Should that not be /usr/lib/brlcad/lib64 ?

/usr/lib/brlcad/bin/mged
Initializing and backgrounding, please wait...Itcl_Init error Can't find a
usable itcl.tcl in the following directories:
    /usr/lib64/brlcad/lib/itcl3.3 ./../lib/itcl3.3 ./../library ./../../library
./../../itcl/library ./../../../itcl/library ./../../../../itcl/library
./../../../../../itcl/library ./src/other/incrTcl/itcl/library
./../src/other/incrTcl/itcl/library ./../../src/other/incrTcl/itcl/library
./../../../src/other/incrTcl/itcl/library
./../../../../src/other/incrTcl/itcl/library
./../../../../../src/other/incrTcl/itcl/library
This probably means that Itcl/Tcl weren't installed properly.
If you know where the Itcl library directory was installed,
you can set the environment variable ITCL_LIBRARY to point
to the library directory.

Can't find a usable itk.tcl in the following directories:
    /usr/lib64/brlcad/lib/itk3.3 ./../lib/itk3.3 ./../library ./../../library
./../../itk/library ./../../../itk/library ./../../../../itk/library
./../../../../../itk/library ./src/other/incrTcl/itk/library
./../src/other/incrTcl/itk/library ./../../src/other/incrTcl/itk/library
./../../../src/other/incrTcl/itk/library
./../../../../src/other/incrTcl/itk/library
./../../../../../src/other/incrTcl/itk/library
This probably means that Itcl/Itk weren't installed properly.
If you know where the Itk library directory was installed,
you can set the environment variable ITK_LIBRARY to point
to the library directory.

MGED Aborted.

Created an attachment (id=136013) [details]
Updated BRL-CAD ebuild - Try a different libdir path for AMD64...

Hmm.  OK, maybe I got too clever for my own good.  It's looking in
/usr/lib64/brlcad/lib, so let's see if this sets it correctly...

Wait, sorry - got ahead of myself.  Where is it actually installing on your
system - is it /usr/lib64/brlcad or /usr/lib/brlcad, and inside that root is it
in lib or lib64?

I was hoping the use of the $(get_libdir) variable would do the "right thing"
for the platform in question, but maybe not...

Created an attachment (id=136014) [details]
One other possibility - need to inherit multilib explicitly?

One other possibility to try - I may have forgotten to pull in a needed eclass
package to make the get_libdir variable do the "right thing".

Sorry for all the guesswork :-(.  If someone can point me to some good docs on
this type of issue with portage/ebuilds I'd be obliged.

/usr/lib is a simlink to /usr/lib64 on *most* AMD64 systems,
but not all.  Something to do with multilib stuff.

bob@tux ~ $ ls /usr/lib -l
lrwxrwxrwx 1 root root 5 Sep  1 04:45 /usr/lib -> lib64
bob@tux ~ $

The real issue is the brlcad/lib vs brlcad/lib64:


bob@tux ~ $ ls /usr/lib64/brlcad/lib
blt2.4  tcl8  tcl8.5  tk8.5
bob@tux ~ $

That is all that is in brlcad/lib.

bob@tux ~ $ ls /usr/lib64/brlcad/lib64
itcl3.3              libitcl3.3.so               libpkg.so
itk3.3               libitcl3.3.so.0             libpkg.so.19
iwidgets4.0.1        libitcl3.3.so.0.0.0         libpkg.so.19.0.1
[and lots more]
libfft.so.19.0.1     liboptical.so.19.0.1        tclConfig.sh
libitcl.a            liborle.a                   tk8.5
libitcl.la           liborle.la                  tkConfig.sh
libitcl.so           liborle.so                  tkimg.a
bob@tux ~ $

is in lib64.

Should there be a brlcad/lib at all?

I had hoped that using $(get_libdir) where I did in the configure script with
the most recent ebuild (which inherits multilib eclass) might do the "right
thing" - it SEEMS like there should be a way to provide the correct options to
make this work.  If there are any "hard coded" instances of lib anywhere that
might be a problem, but it's rather difficult to test on my system since all
I've got anywhere is lib :-/.

I think I messed up the first use of $(get_libdir) by not inheriting the
eclass, so there's a chance it will behave differently now, but the only way to
test it is for someone to try it unless there's a way to "fake" that part of
the ebuild expansion.  (Or, alternately, someone could watch the build until
they spot the configure options and then kill it...)

Hi,

I bumped brlcad-7.10.4 in the science overlay. I will probably not have time to
maintain it, so feel free to submit patches here (as txt files) that I can
quickly commit to the overlay. Once the ebuild stable, it may go to the main
tree.

There are many changes since the last attachment, so please review them as much
as you can. The main problem I encountered was the tcl-8.5 dependencies. I
tried using the masked ones from the tree, but then all other tcl/tk packages
required for brlcad would fail the configure tests. Building brlcad from system
libs would be really nice and for sure would speed up its inclusion in main
tree.


For those not yet familiar with the science overlay, see
http://www.gentoo.org/proj/en/overlays/userguide.xml and use layman -a science.


Thanks all for your work!

First off - thank you!

Looking over the ebuild in the sci overlay, I have a couple of questions:

Is it OK use /usr/brlcad for this?  Most of the reason for the multilib logic
was to be able to use /usr/lib/brlcad (or /usr/lib64/brlcad) automatically.  I
can't remember precisely where I got it but I had found somewhere a suggestion
that installing things into /usr/$APP directories was discouraged by Gentoo
Policy.  Is that not actually the case?

Also, the patch changes the Makefile.in files and not the pre-existing
makefiles - hence re-running the autogen routines.  Did you test the sci
overlay ebuild with the file overwrite protections on?  Perhaps it's not needed
but I had assumed the autogen script was needed to propagate the changes from
the Makefile.in files to the actual Makefiles

Hopefully building with system libs will come in a future version of BRL-CAD,
but there are at least a couple of the libs that either don't have ebuilds or
have ebuilds only in the overlays.  Getting such a BRL-CAD ebuild in the main
tree would require a coordinated introduction of supporting ebuilds as well. 

 > Is it OK use /usr/brlcad for this?  

It's either this simple way or a fully patched ebuild to respect FHS. Since
brl-cad overwrites the name of a whole lot of libraries (such as librt from
glibc), we need to put it somewhere not dangerous. And I noticed if we specify
more dir options, it will start dropping files (like html, ex) all over the
system. So it would need to patch a bunch of Makefiles. The solution right now
is not optimum since it still pollutes the /usr/brlcad/doc with useless files.

> but I had assumed the autogen script was needed to propagate the changes from
> the Makefile.in files to the actual Makefiles

The autogen.sh script builds the configure script. The configure script takes
the Makefile.ins and produces the Makefiles.

> Hopefully building with system libs will come in a future version of BRL-CAD,
> but there are at least a couple of the libs that either don't have ebuilds or
> have ebuilds only in the overlays.  Getting such a BRL-CAD ebuild in the main
> tree would require a coordinated introduction of supporting ebuilds as well. 

Which ones we don't have ebuilds? In the overlay we have tkimg, tnt and jama.

(In reply to comment #111)

> And I noticed if we specify more dir options, it will start dropping files
> (like html, ex) all over the system. So it would need to patch a bunch of
> Makefiles. 

Can you provide a little more detail on that behavior?  There is upstream
interest in understanding and possibly correcting the behavior you're seeing.

(In reply to comment #111)

> Which ones we don't have ebuilds? In the overlay we have tkimg, tnt and jama.

Oh, good - I didn't realize you had all of those.  The remaining fly in the
soup is probably opennurbs, which isn't required now but may be fairly soon.

opennurbs (http://www.opennurbs.org/) is a bit odd - it's got a download form
requirement, but its license seems to be very liberal.  If Gentoo wanted to
have an easy-to-install ebuild it would require re-hosting the file in question
(preferably rebundled as a tar.gz with a version number...) or doing some kind
of fetch restrictions ala the old sun-jdk installs.  Also it seems to have a
version of zlib bundled, so that would need to be patched to use the system
version...

Is anyone working on opennurbs for an ebuild?  And does Gentoo have provisions
for hosting a file when there are non-license-required fetch restrictions?

Created an attachment (id=139280) [details]
brlcad-cvs ebuild

tcl/tk doc-Makefile patch not needed any more

Created an attachment (id=139282) [details]
no need to check for /usr/local

a trivial patch file to be used by brlcad-cvs ebuild

Created an attachment (id=139283) [details]
brlcad-7.10.4-r2

it builds and runs for me now.

the tcl/tk Makefiles still need the patch for do-docs.

some broken symlink for libraries. I'm using a naive fix for librt

Created an attachment (id=139284) [details]
brlcad-9999-r1.ebuild

some minor changes.
the /usr/local patch still included.
http://bugs.gentoo.org/attachment.cgi?id=139282

hopefully, /etc/env.d/99brlcad is correct now

Created an attachment (id=139319) [details]
brlcad-7.10.4-r2.ebuild

make the 7.10.4

http://sourceforge.net/project/showfiles.php?group_id=105292 shows source files
by arch. we should better to include this feature in SRC_URI

Created an attachment (id=149864) [details]
brlcad-7.12.0.ebuild

here's one for 7.12.0, only a couple of minor changes
I had to disable autogen.sh (regenerating the configure script instead of using
the default seemed to stop things from working on amd64 at least)
also the data files should now be located within /usr/share/brlcad instead of
/usr/share directly

remember to log out, log back in again after installing to make sure
ITK_LIBRARY ITCL_LIBRARY is updated in the environment variables

Created an attachment (id=152375) [details]
brlcad-7.12.2.ebuild

version updated, no changes to the ebuild

i'm really interested in this package, can anyone maintain it anywhere?
(sunrise? maybe even portage?)

argh, i'm sorry guys, i *really* read the comments, but i obviously missed
"science overlay" about a million times. sry.

Version 7.10.4 is affected by this bug
http://bugs.gentoo.org/show_bug.cgi?id=225999

Are the last versions affected also?

When I try to run mged I get this:

Can't find a usable tk.tcl in the following directories: 
    /usr/brlcad/lib/tk8.5

/usr/brlcad/lib/tk8.5/tk.tcl: no event type or button # or keysym
no event type or button # or keysym
    while executing
"bind Listbox <MouseWheel> {
        %W yview scroll [expr {- (%D / 120) * 4}] units
    }"
    invoked from within
"if {[tk windowingsystem] eq "aqua"} {
    bind Listbox <MouseWheel> {
        %W yview scroll [expr {- (%D)}] units
    }
    bind Listbox <Option-Mou..."
    (file "/usr/brlcad/lib/tk8.5/listbox.tcl" line 182)
    invoked from within
"source /usr/brlcad/lib/tk8.5/listbox.tcl"
    (in namespace eval "::" script line 1)
    invoked from within
"namespace eval :: [list source [file join $::tk_library $file.tcl]]"
    (procedure "SourceLibFile" line 2)
    invoked from within
"SourceLibFile listbox"
    (in namespace eval "::tk" script line 4)
    invoked from within
"namespace eval ::tk {
        SourceLibFile button
        SourceLibFile entry
        SourceLibFile listbox
        SourceLibFile menu
        SourceLibFile panedwindow
        SourceLibFile ..."
    invoked from within
"if {$::tk_library ne ""} {
    proc ::tk::SourceLibFile {file} {
        namespace eval :: [list source [file join $::tk_library $file.tcl]]
    }
   ..."
    (file "/usr/brlcad/lib/tk8.5/tk.tcl" line 401)
    invoked from within
"source /usr/brlcad/lib/tk8.5/tk.tcl"
    ("uplevel" body line 1)
    invoked from within
"uplevel #0 [list source $file]"


This probably means that tk wasn't installed properly.

MGED Aborted.

Created an attachment (id=167322) [details]
Patch to brlcad internal tk build

This patch fixes the issue with the new Xorg-server 1.5 and Tk that I mentioned
in the comment above. It patches the internal tk source of brlcad. Tested with
ebuild 7.12.2

Is this ready to go to maintainer-wanted and sunrise?

(In reply to comment #125)
> Is this ready to go to maintainer-wanted and sunrise

Why? This is already in the science overlay, comment #109.

ACCEPT_KEYWORDS="~x86"  emerge -av brlcad

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild  N    ] sci-libs/tnt-3.0.10  49 kB [1]
[ebuild  N    ] sci-libs/jama-1.2.5  USE="-doc" 16 kB [1]
[ebuild  N    ] sci-misc/brlcad-7.10.4  USE="-debug -examples" 22,437 kB [1]

Total: 3 packages (3 new), Size of downloads: 22,502 kB
Portage tree and overlays:
 [0] /usr/portage
 [1] /usr/portage/local/layman/science

Would you like to merge these packages? [Yes/No] yes

>>> Verifying ebuild manifests

!!! Digest verification failed:
!!! /usr/portage/local/layman/science/sci-misc/brlcad/ChangeLog
!!! Reason: Filesize does not match recorded size
!!! Got: 917
!!! Expected: 703

For anyone working this, the upcoming 7.14.4 release (by end of Feb) includes
some new search logic that allows arbitrary mixtures of system and non-system
installs of incrTcl and Tcl/Tk.  In the past (as mentioned by others in this
thread), you could encounter an Itcl_Init failure when running mged that should
now be taken care of.  Moreover, the fix also allows for a more varied matching
back-support for 8.4 or 8.5 Tcl/Tk (the latter recommended) as well as Itcl 3.2
or 3.3 (latter required if 8.5).

It would be nice to have some closure on our portage integration if there is a
maintainer willing to keep it up to date.  I think there have been four
releases or so since the last update.

Created an attachment (id=183556) [details]
brlcad-7.12.6.ebuild

ebuild for 7.12.6
needs the usr-local.patch

(In reply to comment #124)
> Created an attachment (id=167322) [edit] [details]
> Patch to brlcad internal tk build
> 
> This patch fixes the issue with the new Xorg-server 1.5 and Tk that I mentioned
> in the comment above. It patches the internal tk source of brlcad. Tested with
> ebuild 7.12.2
> 

I couldn't user this brlcad-tk patch. mged segfaults on opening database

If you're segfaulting trying to use the graphical file open dialog, I saw
similar behavior here - clicking on a file in the dialog caused a Tk level
failure and segfault.  Upgrading to tcl/tk 8.5.6 has fixed it here, but that
won't be in a release until 7.14.4 (coming very soon.)

(In reply to comment #131)
> If you're segfaulting trying to use the graphical file open dialog, I saw
> similar behavior here - clicking on a file in the dialog caused a Tk level
> failure and segfault.  Upgrading to tcl/tk 8.5.6 has fixed it here, but that
> won't be in a release until 7.14.4 (coming very soon.)
> 

I have exactly tcl/tk-8.5.6

I got ekiga-3.0.2 segfaults also, not sure the gtk errors there related or not 

Created an attachment (id=186392) [details]
brlcad-7.14.4.ebuild

this will build 7.14.4, but many USE flags ignored here.

need more investigation here.

you would need tcl/tk-8.5

Created an attachment (id=192384) [details]
brlcad-7.14.8.ebuild

brlcad-7.14.8.ebuild
need some work to clean up leftovers from previous versions, but this ebuild
emerges and works for me.

Created an attachment (id=192428) [details]
brlcad-7.14.8.ebuild

updated env.d, no need to set LDPATH etc.

7.18.4 is out by now .. is anyone going to add it to the science overlay? -
would be nice ;)

sorry meant 7.14.8

put 7.14.8 in my overlay for now ..

The location of the havoc.g file seems to have changed. the correct einfo line
should be as follows: (updated in my dev overlay)

einfo "${brlcadprefix}/bin/mged ${brlcadprefix}/share/brlcad/${PV}/db/havoc.g"

It's not moved, the ebuild has just been wrong since after one of the 7.10
updates and nobody noticed.

A few other notes about the ebuild:

1) blt is no longer a dependency so should remove the DEPEND line and the
--enable-libblt-build compile option.

2) there's no code limitation that limits compilation to just ~amd64 ~x86. 
should compile on pretty much anything Gentoo supports.

3) --enable-documentation, --enable-models, --enable-iwidgets-build,
--enable-libblt-build, and --enable-opennurbs-build should be removed as they
do nothing or in the case of a couple are at least unnecessary.  the
--enable-iwidgets-build option conflicts with setting dev-tcltk/iwidgets as a
dependency.  If --enable-documentation is going to be added, there are
additional dependencies that should be specified.  default behavior on most
configure options is auto-detect and enabling a build without the dependency
will result in a configure abort.

4) should declare a DEPEND dependency on a lexer/parser (e.g., bison/flex). 
not strictly required, but will provide desirable functionality.

5) most of the commented lines should just be removed as they are out-dated
(except MANPATH, should set that, but not the rest).

6) The postinst message should refer users to
http://brlcad.org/wiki/Documentation in addition to the path to havoc.g being
wrong.

Cheers!
Sean

Created an attachment (id=193188) [details]
brlcad-7.14.8.ebuild

updated configure options, I still don't know what DEPENDs for USE=doc

For USE=docs, the minimal dependency is xsltproc.  That will build and install
the html documentation.  To also generate that same documentation in pdf
format, it will need Apache FOP.

We're about to push out a 7.16.0 release for the end of August (i.e., today).

Created an attachment (id=209074) [details]
brlcad-7.16.0.ebuild

only tested on x86_64.

http://bugs.sabayonlinux.org/show_bug.cgi?id=996

brlcad-7.16.0.ebuild works for me.

Also tested in x86_64

Good job!

Created an attachment (id=212388) [details]
brlcad-7.16.2.ebuild

brlcad-7.16.2.ebuild

Created an attachment (id=212390) [details]
cut-7.16.2.patch

Created an attachment (id=212391) [details]
cmd-7.16.2.patch

Created an attachment (id=212392) [details]
xsltproc-7.16.2.patch

Thanks for the patches, dongxu_li!  Your changes, with the exception of the
xsltproc patch, have all been committed to the repository and will be part of
the upcoming 7.16.4 release (due to be posted this week).

A change was made to our configure.ac template that should affect the xsltproc
patch, but you shouldn't be setting the XSLTPROC variable directly in the
Makefile.am as it's an AC_SUBST variable set by configure.  My suspicion is
that the variable was empty, causing a build failure, which shouldn't happen
after my recent change.  Why it failed to detect xsltproc for you should be
described in your config.log file (and would be useful to know).

Cheers!
Sean

Created an attachment (id=212436) [details]
config.log with empty XSLTPROC

the problem seems be to from --disable-documentation.

with --disable-documentation, XSLTPROC is not set, but doc/dockbook still being
built. need to check why doc/docbook is still being used with
--disable-documentation

Ah, yeah, that would explain things.  The configure.ac template had some lame
logic that made it skip searching for xsltproc if you disabled documentation. 
It shouldn't have been traversing into doc/docbook if docs are disabled
regardless, but the patch I applied will take care of that issue indirectly by
at least making sure XSLTPROC is ":".  Now even if documentation is disabled,
it shouldn't fail even if the build (or builder) does get into the doc/docbook
directory.

Chers!
Sean

Created an attachment (id=216212) [details]
small logic fix that only affects x86_32

the ebuild from dongxu li contains a small logic error that makes the build to
attempt to build as x86_64 on 32-bit systems. this ebuild fixes that and makes
it build nicely on my old laptop.

regards,
m.b.

# diff -Naur brlcad-7.16.2.ebuild brlcad-7.16.2-r1.ebuild 
--- brlcad-7.16.2.ebuild        2010-01-12 12:01:56.012227809 +0100
+++ brlcad-7.16.2-r1.ebuild     2010-01-12 12:52:55.357227915 +0100
@@ -64,7 +64,7 @@
         $(use_enable debug warnings) \
         $(use_enable debug progress) \
                "
-       use amd64 || myconf="${myconf} --enable-64bit"
+       use amd64 && myconf="${myconf} --enable-64bit"
        use debug || myconf="${myconf} --enable-optimized"
        ./configure $myconf || die "configure failed"
        emake || die "emake failed"

Great work!

I noticed that the old ebuild fails on x86_32, but didn't try to troubleshoot.

(In reply to comment #153)
> Created an attachment (id=216212) [details] [details]
> small logic fix that only affects x86_32
> 
> the ebuild from dongxu li contains a small logic error that makes the build to
> attempt to build as x86_64 on 32-bit systems. this ebuild fixes that and makes
> it build nicely on my old laptop.
> 
> regards,
> m.b.
> 
> # diff -Naur brlcad-7.16.2.ebuild brlcad-7.16.2-r1.ebuild 
> --- brlcad-7.16.2.ebuild        2010-01-12 12:01:56.012227809 +0100
> +++ brlcad-7.16.2-r1.ebuild     2010-01-12 12:52:55.357227915 +0100
> @@ -64,7 +64,7 @@
>          $(use_enable debug warnings) \
>          $(use_enable debug progress) \
>                 "
> -       use amd64 || myconf="${myconf} --enable-64bit"
> +       use amd64 && myconf="${myconf} --enable-64bit"
>         use debug || myconf="${myconf} --enable-optimized"
>         ./configure $myconf || die "configure failed"
>         emake || die "emake failed"
> 

Created an attachment (id=217342) [details]
brlcad-7.16.4.ebuild

version bump to 7.16.4

CFLAGS="-Werror" breaks upon src/libbu/bomb.c

Have to be filtered out currently.

You don't have to filter it out.  If you add the --disable-strict configure
flag, it will remove -Werror from the build.

(In reply to comment #156)
> You don't have to filter it out.  If you add the --disable-strict configure
> flag, it will remove -Werror from the build.
> 

I think the source code should be fixed to allow -Werror.

thanks!

Even better, patches welcome!

One noteworthy point, though, is that the flag being enabled is not technically
just -Werror.  That is of course a good flag to enable by itself, but we go
above and beyond by asking the compiler to report nearly everything it's
capable of reporting.  That results in a LOT of platform variability, compiler
version variability, and *many* false positives, so package distribution
systems like portage *should* disable the behavior.

We've been moving towards what we call "strict" compilation of all our core
libraries where nearly all warnings are enabled (not just -Wall, but even many
optional ones that default off), so we can of course address them all (even the
false positives).  That's not a burden intended for the general public, even if
we made it default behavior.  That was done for other (selfish) reasons.

Hi folks,

I rewrote the ebuild from scratch and bumped to 7.16.4 it in the science
overlay with an as-needed patch, and now almost uses exclusively system
libraries.

Let me ask again: who is interested in maintaining it either in the science
overlay or as a proxy maintainer? I won't.

Uhm ... 7.16.4 from the science overlay fails with extremely weird file
collisions for me:

 * Searching all installed packages for file collisions...
 * 
 * Press Ctrl-C to Stop
 * 
 * sys-apps/coreutils-7.5-r1
 *      /usr/share/man/man1/cat.1.bz2
 *      /usr/share/man/man1/cp.1.bz2
 * 
 * sys-apps/man-1.6f-r3
 *      /usr/share/man/man1/apropos.1.bz2
 * 
 * sys-apps/attr-2.4.43
 *      /usr/share/man/man1/attr.1.bz2
 * 
 * Package 'sci-misc/brlcad-7.16.4' NOT merged due to file collisions. If
 * necessary, refer to your elog messages for the whole content of the
 * above message.

Why would brlcad want to replace those man-pages?

i forgot:

# emerge --info
Portage 2.2_rc62 (default/linux/x86/10.0, gcc-4.3.4, glibc-2.10.1-r1,
2.6.31-gentoo-r6 i686)
=================================================================
System uname:
Linux-2.6.31-gentoo-r6-i686-Genuine_Intel-R-_CPU_T2300_@_1.66GHz-with-gentoo-2.0.1
Timestamp of tree: Wed, 03 Feb 2010 22:45:01 +0000
distcc 3.1 i686-pc-linux-gnu [enabled]
ccache version 2.4 [enabled]
app-shells/bash:     4.0_p35
dev-java/java-config: 2.1.10
dev-lang/python:     2.6.4
dev-python/pycrypto: 2.1.0_beta1
dev-util/ccache:     2.4-r7
dev-util/cmake:      2.6.4-r3
sys-apps/baselayout: 2.0.1
sys-apps/openrc:     0.6.0-r1
sys-apps/sandbox:    2.2
sys-devel/autoconf:  2.13, 2.63-r1
sys-devel/automake:  1.8.5-r3, 1.9.6-r2, 1.10.2
sys-devel/binutils:  2.18-r3
sys-devel/gcc:       4.3.4
sys-devel/gcc-config: 1.4.1
sys-devel/libtool:   2.2.6b
virtual/os-headers:  2.6.27-r2
ACCEPT_KEYWORDS="x86"
ACCEPT_LICENSE="*"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-march=prescott -O2 -pipe -fomit-frame-pointer -m32"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/X11/xkb /var/lib/hsqldb"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/
/etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild
/etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d
/etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c
/etc/udev/rules.d"
CXXFLAGS="-march=prescott -O2 -pipe -fomit-frame-pointer -m32"
DISTDIR="/usr/portage/distfiles"
EMERGE_DEFAULT_OPTS="--jobs=6 --load-average=3"
FEATURES="assume-digests ccache distcc distlocks fixpackages news
parallel-fetch preserve-libs protect-owned sandbox sfperms strict unmerge-logs
unmerge-orphans userfetch webrsync-gpg"
GENTOO_MIRRORS="http://de-mirror.org/distro/gentoo/ http://gentoo.mneisen.org/
http://gentoo.supp.name/"
LANG="de"
LDFLAGS="-Wl,-O1"
LINGUAS="de en sv fr ru"
MAKEOPTS="-j5 --load-average=3"
PKGDIR="/usr/portage/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_EXTRA_OPTS="--delete-after"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress
--force --whole-file --delete --stats --timeout=180 --exclude=/distfiles
--exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/portage/local/layman/science
/usr/portage/local/layman/java-overlay /usr/portage/local/layman/x11
/usr/portage/local/layman/sunrise /usr/portage/local/mine"
SYNC="rsync://10.2.3.4/gentoo-portage"
USE="X a52 aac aalib accessibility acl acpi alsa amr aotuv archive
bash-completion berkdb blksha1 boost branding bzip2 cairo cdda cddax cdr
cleartype cli cracklib crypt css cups cxx dbus device-mapper dga dia
disk-partition doc dri dvd dvdr enca encode exif fam fat ffmpeg flac foomaticdb
fortran frei0r ftp fuse gd gdbm geoip gif gimp git glitz gnome gphoto2 gpm gre
gs gstreamer gtk hal hddtemp hpn iconv id3tag idn inkjar iostats ipv6 jabber
java java6 javascript jpeg jpeg2k kpathsea ladspa laptop latex libass libcaca
libnotify libv4l2 live lm_sensors lock lzma lzo mad matroska mime mjpeg mmap
mmx mmxext mng modules mp2 mp3 mp4 mpeg mplayer mudflap music ncurses network
nls nodrm nptl nptlonly nsplugin ntfs ntp octave offensive ogg opengl openmp
pam pcre pdf perl png postscript ppds pppd python qt4 quicktime rar readline
reflection reiser4 reiserfs rss rtc samba schroedinger sdl session skins smp
sound speex spl sse sse2 ssl startup-notification stk subtitles subversion svg
symlink sysfs tcpd templates theora threads thunar tidy tiff trayicon truetype
twolame unicode upnp usb v4l2 vcd video videos vim-syntax vim-with-x vorbis vst
weather-metar weather-xoap webkit wifi wma wps wxwidgets x264 x86 xanim xcb
xcomposite xfce xhtml xinerama xml xorg xosd xpm xscreensaver xv xvid xvmc zip
zlib" ALSA_CARDS="hdmi" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare
dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter
mmap_emul mulaw multi null plug rate route share shm softvol"
APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm
authn_default authn_file authz_dbm authz_default authz_groupfile authz_host
authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir
disk_cache env expires ext_filter file_cache filter headers include info
log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling
status unique_id userdir usertrack vhost_alias" ELIBC="glibc"
INPUT_DEVICES="synaptics evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz
cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="de en sv fr
ru" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="radeon" 
Unset:  CPPFLAGS, CTARGET, FFLAGS, INSTALL_MASK, LC_ALL, PORTAGE_COMPRESS,
PORTAGE_COMPRESS_FLAGS

it should not happen, because everything is installed under /usr/brlcad/, with
the except of /etc/env.d/

I have no idea how your ebuild generated the collision. It's impossible to
me.Try to clean up /var/tmp/portage (it's auto, anyway), and

emerge -va brlcad

(In reply to comment #160)
> Uhm ... 7.16.4 from the science overlay fails with extremely weird file
> collisions for me:
> 
>  * Searching all installed packages for file collisions...
>  * 
>  * Press Ctrl-C to Stop
>  * 
>  * sys-apps/coreutils-7.5-r1
>  *      /usr/share/man/man1/cat.1.bz2
>  *      /usr/share/man/man1/cp.1.bz2
>  * 
>  * sys-apps/man-1.6f-r3
>  *      /usr/share/man/man1/apropos.1.bz2
>  * 
>  * sys-apps/attr-2.4.43
>  *      /usr/share/man/man1/attr.1.bz2
>  * 
>  * Package 'sci-misc/brlcad-7.16.4' NOT merged due to file collisions. If
>  * necessary, refer to your elog messages for the whole content of the
>  * above message.
> 
> Why would brlcad want to replace those man-pages?
> 

Hmm.

Maybe you checked your own ebuild? The ebuild that ended up in the science
overlay was rewritten. Severely.