01:12.07 |
brlcad |
updates the ideas list
http://brlcad.org/wiki/Google_Summer_of_Code/Project_Ideas |
01:12.20 |
brlcad |
it's closer to a "final initial" form
now |
02:22.51 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
04:01.54 |
hippieindamakin8 |
nice list man |
04:02.47 |
brlcad |
coming together bit by bit |
04:03.01 |
yukonbob |
looks |
04:07.34 |
yukonbob |
brlcad: interested in my latest build issues,
or should I plug away solo? |
04:10.07 |
yukonbob |
http://pastebin.ca/953538 |
04:22.06 |
yukonbob |
that test code needs an "#include
<stdlib.h>" for exit() |
05:09.24 |
yukonbob |
(/me assumes introduced at 30538,
configure.ac)? But seems completely ac-generated... wft? |
05:09.30 |
yukonbob |
*wtf |
05:10.17 |
brlcad |
yukonbob: yeah weird |
05:10.43 |
brlcad |
the sanity check is missing a header it seems
.. that C mode is fine with but C++ mode is adament about |
05:11.00 |
brlcad |
there was a new C++ mode sanity check added
just a couple days ago (right after 7.12.0 |
05:12.34 |
CIA-33 |
BRL-CAD: 03brlcad * r30554
10/brlcad/trunk/m4/compiler.m4: bah, need stdlib.h for exit().. C++
sanity check seems insistent on needing it. |
05:12.42 |
yukonbob |
ya -- is BC_SANITY_CHECK a builtin, or
user-supplied |
05:13.29 |
brlcad |
all BC_'s are brl-cad macros in m4/ |
05:13.33 |
yukonbob |
whatever you just modded could stand to lose
stdio, I believe, too -- probably somebody's finger-memory got the
best of them at that point.. |
05:13.44 |
brlcad |
true |
05:13.56 |
brlcad |
stdio was providing exit() on older
glibc |
05:14.46 |
CIA-33 |
BRL-CAD: 03brlcad * r30555
10/brlcad/trunk/m4/compiler.m4: don't need stdio.h |
05:14.47 |
yukonbob |
doesn't remember that; if it
does/did, so be it, but that won't matter on *BSD, etc. They'll
need stdlib |
05:15.39 |
yukonbob |
might end up learning
autotools if he's not careful here |
05:16.46 |
yukonbob |
does my commit-bit extend to code as well, or
strictly doc? |
05:17.00 |
brlcad |
to anything |
05:17.01 |
yukonbob |
hasn't tried, and we've not
talked about this |
05:17.32 |
brlcad |
don't worry about mixing up other stuff, dive
right in ;) |
05:19.07 |
yukonbob |
alright; I'm still getting that itcl error
that was the initial issue, but working on other stuff too (like
the above c++); autogen.sh isn't liking my build env (pkgsrc), but
doesn't mind a by-hand run from the shell; I'll explore that too --
(autogen itself hasn't changed, but it must include some changed
files, because it used to work np) |
05:19.14 |
brlcad |
all commits are reviewed anyways and announced
here so it's easy enough to see what's going on |
05:19.43 |
yukonbob |
nods |
05:19.46 |
brlcad |
does "sh autogen.sh -v" show
anything? |
05:21.11 |
yukonbob |
can check; in the
"environment" build, it chokes on autoreconf, then tries it's
"manual config" (or whatever) and chokes on that,
too. |
05:21.44 |
yukonbob |
by-hand, everything works fine... which is
strange to me, but I'll track down what the offending difference
is... |
05:22.13 |
brlcad |
-v will show the exact commands it's trying to
run |
05:22.29 |
yukonbob |
nods, add to
wrapping-Makefile |
05:22.50 |
yukonbob |
*adds |
05:23.23 |
brlcad |
which is a version check for autoconf,
automake, and libtool .. then something like "autoreconf -v -i -s"
.. and then individual steps if that fails |
05:24.22 |
yukonbob |
_has_ autoreconf, and even
supplied it directly via the AUTORECONF env var, but no
dice |
05:25.09 |
yukonbob |
runs build |
05:25.10 |
brlcad |
autoreconf can fail for lots of
reasons |
05:25.46 |
brlcad |
that's one of many reasons why autogen.sh
exists in the first place |
05:25.59 |
yukonbob |
out of comlete curiousity, how much effort do
you think it'd take to replace auto* w/ cmake (for example) and
what would keep one from doing that, besides the
manpower? |
05:26.09 |
yukonbob |
*complete |
05:27.07 |
brlcad |
manpower to replicate the entire build system
faithfully, I'd expect it'd take many months |
05:27.16 |
brlcad |
of non-stop effort |
05:27.29 |
yukonbob |
! |
05:28.13 |
brlcad |
the conversion to autotools took a long time,
about that long, and there wasn't really any complicated road
blocks |
05:28.35 |
yukonbob |
everybody likes to complain about "autohell";
what's your take on it? |
05:28.42 |
brlcad |
it just takes a lot of work to specify the
build rules for 400+ binary targets, the 24 or so libs, and various
types of data files and subdependencies |
05:30.31 |
brlcad |
autohell is the way it is for many
reasons |
05:31.27 |
brlcad |
it does what it does the way it does it in
order to provide strict portability constraints (that really cannot
be easily provided most any other way without adding
dependencies) |
05:32.52 |
yukonbob |
have you ever played w/ scons (python), or
cmake? |
05:32.58 |
brlcad |
yep |
05:34.16 |
brlcad |
i actually rather like cmake, their biggest
claim to awesomeness is thier ability to export the various build
systems (including msvc files) from one description |
05:34.50 |
brlcad |
scons is nice for small code sets but
*seriously* starts to fall apart on large complex build systems --
you basically end up reimplementing autoconf |
05:35.16 |
yukonbob |
ya -- /me is ready to buy the cmake manual
(just released (new version)) and check it out... |
05:37.29 |
brlcad |
like a lot of tools though, autotools really
do work (and work well once you get over the learning curve) and it
really starts to make sense why things are the way they
are |
05:38.31 |
brlcad |
their biggest downfall has been practical
usability problems (horrible error messages, bad docs, elitist
responses to usability) |
05:39.17 |
yukonbob |
speaking of docs, can you recommend any? The
GNU-supplied stuff isn't my cup of tea. |
05:44.30 |
brlcad |
I actually recommend just reading existing
build files for projects that use the autotools -- it's fairly
straight-forward seeing it in other apps as there are really only
two or three files types involved |
05:44.35 |
brlcad |
the configure.ac and the Makefile.am
files |
05:45.38 |
brlcad |
the Makefile.am files don't really get *any*
simpler in any of the autotools/cmake/ant/scons/whatever build
systems as it's just a list of targets, sets of files, and how
those sets of files relate to those targets |
05:47.49 |
brlcad |
the build/feature/header tests and project
identification are somewhat tricky in all the systems to replicate
-- that's where configure.ac comes into play for the
autotools |
05:48.55 |
brlcad |
which is just shell syntax with
macros |
05:49.22 |
yukonbob |
nods -- will probably start
poking this stuff in BRLCAD, and probably pick your brain too,
where possible ;) |
05:49.32 |
brlcad |
feel free to |
05:50.40 |
brlcad |
I've read the GNU book and the auto* manuals,
but I really never learned it until I put it to use |
05:51.32 |
brlcad |
the tools are overly flexible, making it
really complicated to document since you can approach things in a
variety of ways (even though 90% of projects all do it about the
same) |
05:52.01 |
yukonbob |
that might be my problem -- the gnu manuals
are drier than toast (and technical manuals don't have to be that
way); maybe those in conjunction w/ some interesting "real life"
work will click |
05:52.29 |
brlcad |
in hindsight after you've put it to use, it
does all make sense |
05:52.36 |
brlcad |
even becomes somewhat overly obvious |
05:52.46 |
brlcad |
but is totally opaque until you put it to
use |
05:56.38 |
yukonbob |
gets ready for
sleep |
05:56.38 |
brlcad |
usually much more effective to just look at a
project that is already set up (like brl-cad or something even more
simple) and follow their example |
05:56.54 |
yukonbob |
nice chatting again, brlcad; probably talk
tmo, or soon at least. |
05:56.56 |
yukonbob |
:) |
05:57.00 |
brlcad |
aiight |
05:57.01 |
brlcad |
cheers |
06:47.50 |
CIA-33 |
BRL-CAD: 03brlcad * r30556
10/brlcad/trunk/HACKING: the dutch cad4linux site seems to be now
defunct |
07:10.07 |
CIA-33 |
BRL-CAD: 03brlcad * r30557
10/brlcad/trunk/HACKING: add devmaster to the notification
list |
08:57.35 |
*** join/#brlcad homovulgaris
(n=ca3fe93d@bz.bzflag.bz) |
09:00.44 |
brlcad |
uploads some new images to
the gallery |
09:43.46 |
brlcad |
ensleeps |
09:51.41 |
*** join/#brlcad cad22
(n=52f7631d@bz.bzflag.bz) |
09:56.28 |
*** part/#brlcad cad22
(n=52f7631d@bz.bzflag.bz) |
14:15.47 |
*** join/#brlcad Elperion
(n=Bary@p54875E2A.dip.t-dialin.net) |
15:58.51 |
*** join/#brlcad vedge
(n=vedge@vedge.org) |
16:14.45 |
brlcad |
time for a sunday feast! |
16:36.04 |
yukonbob |
morning brlcad... happy Easter |
16:37.06 |
poolio |
happy purim :) |
16:37.30 |
yukonbob |
looks up
purim |
16:46.01 |
brlcad |
likewise |
16:46.33 |
brlcad |
bah, can't find the original bradley
rendering... |
17:10.30 |
yukonbob |
would love to see
that |
17:17.23 |
yukonbob |
http://my.brlcad.org/gallery/gallery/s/historic/particles.jpg.html |
17:18.03 |
yukonbob |
^-- what is this, and it reminds me of a
question I've had for a while: what's the 'atom' for? |
17:27.23 |
*** join/#brlcad Elperion
(n=Bary@p54875E2A.dip.t-dialin.net) |
17:28.11 |
brlcad |
frankly I don't know really :) the image is
an old one from bill laut .. don't know what he used it for, I'd
have to ask him |
17:28.27 |
brlcad |
as for the atom? which/what atom? |
17:33.11 |
*** join/#brlcad Elperion
(n=Bary@p54875E2A.dip.t-dialin.net) |
17:35.53 |
brlcad |
few more images uploaded |
17:39.02 |
yukonbob |
is sure he's seen an "atom"
primitive |
17:39.45 |
yukonbob |
also doesn't have a copy of
BRL-CAD installed atm, and is heading out for easter brunch... chat
later cadheads |
17:41.50 |
*** join/#brlcad Elperion
(n=Bary@p54875E2A.dip.t-dialin.net) |
17:53.27 |
*** join/#brlcad Elperion
(n=Bary@p54875E2A.dip.t-dialin.net) |
20:15.48 |
*** join/#brlcad Elperion
(n=Bary@p54875E2A.dip.t-dialin.net) |
21:56.20 |
yukonbob |
http://pastebin.ca/954422 |
21:56.34 |
yukonbob |
^--- build failure at g-3dm |
22:03.40 |
*** join/#brlcad louipc
(n=louipc@bas8-toronto63-1128543675.dsl.bell.ca) |
22:12.44 |
yukonbob |
traces to
src/conf/.deps/g-3dm.Po... |
22:13.03 |
yukonbob |
...or does he? |
22:17.28 |
yukonbob |
wonders if 3dm is only in
development... |
22:19.02 |
yukonbob |
looks like g-3dm isn't ready, but it included
(erroneosly) in build... |
22:19.31 |
yukonbob |
*erroneously |
22:26.51 |
yukonbob |
puts this on hold -- will
return, test idea, and commit fix (if found)
later. |
23:14.19 |
*** join/#brlcad Elperion
(n=Bary@p54875E2A.dip.t-dialin.net) |
23:18.05 |
*** join/#brlcad Elperion
(n=Bary@p54875E2A.dip.t-dialin.net) |