00:35.44 |
kanzure |
mpictor: i'm sure almost everything in OCC was
built to contract, there was the original CASCADE components but i
don't know if any of them remain.. |
00:43.19 |
mpictor |
kanzure: what I mean is, it's sorta funny that
those ops didn't make it back into occ |
00:43.57 |
mpictor |
they must have been required to licence the
code they were contracted to write exclusively under lgpl |
00:44.01 |
kanzure |
has anyone made a dependency graph of occ? i'm
really curious to see which modules are the root modules. |
01:29.56 |
mpictor |
kanzure: look in OCE's CMakeFiles. for
example: https://github.com/tpaviot/oce/blob/master/CMakeLists.txt#L1170 |
01:39.57 |
kanzure |
okay |
03:19.34 |
starseeker |
mpictor: I haven't had a chance to dig into
that doc - are the SALOME booleans functional for NURBS BReps or
just meshes? |
05:22.55 |
brlcad |
starseeker: so note that the header breakout
is not just code movement |
05:23.26 |
brlcad |
the headers should be properly
encapsulated |
05:23.50 |
brlcad |
meaning they include only and exactly what
they need (and do so without an include cycle) |
05:26.38 |
brlcad |
e.g., new bu/magic.h is no longer
encapsulated, missing the connection through for NO_BOMBING_MACROS,
UNLIKELY, and BU_IGNORE |
05:27.06 |
brlcad |
at a glance, looks like others have similar
issues |
07:14.17 |
brlcad |
``Erik: notify deaded agains |
07:50.14 |
*** join/#brlcad Anaphaxeton
(~george@unaffiliated/anaphaxeton) |
09:01.49 |
*** join/#brlcad hightower4
(~abc@213.147.97.58) |
09:03.30 |
*** join/#brlcad konro
(~konro@41.205.22.53) |
09:05.17 |
*** join/#brlcad konro_
(~konro@41.205.22.53) |
09:22.52 |
*** join/#brlcad merzo
(~merzo@user-94-45-58-138-1.skif.com.ua) |
09:53.10 |
*** join/#brlcad caleb_
(c318dc10@gateway/web/freenode/ip.195.24.220.16) |
10:04.06 |
*** join/#brlcad merzo
(~merzo@user-94-45-58-138-1.skif.com.ua) |
10:25.20 |
*** join/#brlcad luca79
(~luca@net-37-117-82-13.cust.vodafonedsl.it) |
10:26.33 |
*** join/#brlcad caleb_
(c318dc10@gateway/web/freenode/ip.195.24.220.16) |
11:41.08 |
*** join/#brlcad _caleb
(c318dc10@gateway/web/freenode/ip.195.24.220.16) |
12:10.29 |
*** join/#brlcad FreezingCold
(~FreezingC@205.211.50.162) |
12:39.55 |
*** join/#brlcad Amitoj
(7cfd2c3a@gateway/web/freenode/ip.124.253.44.58) |
12:40.38 |
*** join/#brlcad FreezingCold
(~FreezingC@205.211.52.162) |
12:42.42 |
Amitoj |
hello I am Amitoj Singh I want to take part in
GSOC 2014 in BRL-CAD so suggest me where to start |
12:44.42 |
starseeker |
brlcad: noted. My plan was to start adjusting
unit tests for libbu to use only the headers they need and use that
effort to spot/fix any such issues |
12:45.40 |
starseeker |
Amitoj: http://brlcad.org/wiki/Summer_of_Code/Checklist |
12:46.00 |
starseeker |
Or, more broadly, http://brlcad.org/wiki/Google_Summer_of_Code |
12:52.38 |
starseeker |
_caleb: if you're interested in BRL-CAD you
want to be discussing in #brlcad |
12:53.09 |
starseeker |
_caleb: community participation is
vital |
12:53.46 |
_caleb |
startseeker: thanks for the advice |
12:54.00 |
starseeker |
for search exec, the main thing is going to be
how to execute commands on search results |
12:54.28 |
starseeker |
so as a first step, I would study how the UNIX
find command's exec option works |
12:55.01 |
starseeker |
we will be "launching" internal libged
commands instead of programs, but the behavior we're after will be
similar in many other respects |
12:56.06 |
starseeker |
the BRL-CAD file that contains most of our
search implementation is in src/librt/search.c |
12:57.16 |
starseeker |
You'll notice that it re-uses a fair bit of
find code from the NetBSD and OpenBSD find
implementations |
12:58.21 |
starseeker |
but we are working with database objects and
hierarchies rather than file systems |
12:58.41 |
_caleb |
yes i actually got there and tried studying
the code!! kind of interestig! |
12:58.41 |
starseeker |
_caleb: was that what you were looking
for? |
12:59.15 |
_caleb |
yup i thinks that will be a good start for
me!!! thanks alot! |
12:59.35 |
starseeker |
OK, then the other side of the coin is
understanding how a libged function is executed, what its arguments
need to be, and how to handle its results |
12:59.58 |
starseeker |
I would suggest discussing that aspect with
brlcad when he is around |
13:00.19 |
_caleb |
ok! |
13:03.11 |
starseeker |
my expectation is that a lot of the "thorny"
issues will be there - how to convert a "search plan" request into
a libged function call, what to do with the results of the libged
command when stringing multiple -exec options together to allow
proper processing, etc. |
13:04.25 |
starseeker |
it may require some supporting bits that
aren't fully in place yet - brlcad will have the best idea about
what we need to get that aspect working |
13:05.52 |
starseeker |
_caleb: remember IRC isn't truly interactive -
people will come and go, so stay logged in and you may get answers
to your questions hours after they are posted |
13:05.57 |
starseeker |
that's normal and expected |
13:07.21 |
Amitoj |
I am interested in web development so can i
get project related to it i want to contribute in brl-cad |
13:08.30 |
_caleb |
ok! i really find the libged functions not
very easy to understand though i am trying hard to have a grip of
it day an night! |
13:08.48 |
_caleb |
i mean its functioning! |
13:14.43 |
_caleb |
Amitoj try surveying through this project
ideas and you may see something interesting on the Web part!!
http://brlcad.org/wiki/Google_Summer_of_Code/Project_Ideas |
13:15.04 |
``Erik |
brlcad, starseeker: notify itself seems to be
running ok, mail delivery doesn't seem to be happening (or procmail
or spamd are jammed)... system load seems to be at 120, which is a
bit high... a lot of www git-remote-https procs jamming it all up
:/ |
13:15.26 |
Amitoj |
ok thanks |
13:18.46 |
``Erik |
brlcad, starseeker: issue started monday
evening (ls -ltr /var/mail/), not sure if the insane load (which is
somehow related to https://code.google.com/p/soc/)
is the cause of the mta issue |
13:33.17 |
``Erik |
"sendmail: rejecting connections on daemon
MSA: load average: 104 (sendmail)" so I'd imagine those git
processes to the gsoc thing are the culprit |
13:33.37 |
``Erik |
goes whacky with his doom][
pid shotgun |
13:38.16 |
``Erik |
yup, the mail is flowing now |
13:42.15 |
Notify |
03BRL-CAD Wiki:Vaibhavgupta495 * 0
/wiki/User:Vaibhavgupta495: |
13:42.15 |
``Erik |
heh, wasn't a notify problem for once, was a
cascade error started by someones web git thingymajigger
:D |
13:42.40 |
Notify |
03BRL-CAD:carlmoore * 59839
brlcad/trunk/src/libbu/bitv.c: use all capitals for NULL |
13:42.42 |
Notify |
03BRL-CAD:starseeker * 59816
brlcad/trunk/src/libbu/vls.c: always false |
13:42.46 |
Notify |
03BRL-CAD:starseeker * 59815
brlcad/trunk/src/libbu/tests/CMakeLists.txt: Tell CMake about
bitv-tests.cmake |
13:43.10 |
Notify |
03BRL-CAD:starseeker * 59841
brlcad/trunk/src/conv/step/g-ap214/Add_Tree.cpp: Make a note to
check out solid_replica in AP214 |
13:43.22 |
Notify |
03BRL-CAD:tbrowder2 * 59838
brlcad/trunk/include/bu.h: update some more file
references |
13:43.31 |
``Erik |
heh
http://freecode.com/articles/stop-the-autoconf-insanity-why-we-need-a-new-build-system |
13:44.17 |
Notify |
03BRL-CAD:starseeker * 59824
brlcad/trunk/src/conv/step/g-ap214/Add_Tree.cpp: A few tweaks and
notes |
13:44.19 |
Notify |
03BRL-CAD:r_weiss * 59821
(brlcad/trunk/src/util/bw-ps.c brlcad/trunk/src/util/pix-ps.c): Fix
to printf format to work on both windows and linux. |
13:44.26 |
Notify |
03BRL-CAD:tbrowder2 * 59837
brlcad/trunk/include/bu.h: update some file references |
13:44.32 |
Notify |
03BRL-CAD:starseeker * 59836
brlcad/trunk/src/conv/step/g-ap214/Add_Tree.cpp: Walk over region
trees |
13:44.37 |
Notify |
03BRL-CAD:carlmoore * 59823
(brlcad/trunk/src/conv/step/g-ap214/Add_Tree.cpp
brlcad/trunk/src/librt/primitives/nmg/nmg_class.c): remove trailing
blanks/tabs |
13:44.45 |
Notify |
03BRL-CAD:starseeker * 59833
(brlcad/trunk/src/libbu/magic.c
brlcad/trunk/src/librt/primitives/xxx/xxx.c
brlcad/trunk/src/librt/primitives/xxx/xxx.h): Fix references and
includes for magic.h in src |
13:44.50 |
Notify |
03BRL-CAD:brlcad * 59825
(brlcad/trunk/include/bu.h brlcad/trunk/src/libbu/vls.c): note that
the input to bu_vls_substr() is const. also, make the return
pointer from bu_vls_cstr() return const, distinguishing it from
bu_vls_addr() so we can weed out those few places that write to the
memory (instead of making a copy) while callers are
migrated. |
13:44.54 |
Notify |
03BRL-CAD:tbrowder2 * 59842
(brlcad/trunk/src/libbu/tests/CMakeLists.txt
brlcad/trunk/src/libbu/tests/bu_vls_vprintf.c): add two new tests
to prove revision 58221 and disprove its reversion at revision
58231 |
13:45.10 |
Notify |
03BRL-CAD:r_weiss * 59819
(brlcad/trunk/src/util/bw-ps.c brlcad/trunk/src/util/bwhisteq.c
brlcad/trunk/src/util/pix-ps.c): Improve fixes to quieting windows
build warnings. |
13:45.16 |
Notify |
03BRL-CAD:starseeker * 59831
(brlcad/trunk/src/libbn/tests/bn_poly_add.c
brlcad/trunk/src/libbn/tests/bn_poly_cubic_roots.c and 5 others):
don't include magic.h explicitly |
13:45.19 |
Notify |
03BRL-CAD:starseeker * 59834
(brlcad/trunk/include/bu/magic.h brlcad/trunk/include/bu.h):
Consolidate other magic header stuff into bu/magic.h |
13:45.31 |
Notify |
03BRL-CAD:starseeker * 59820
brlcad/trunk/src/conv/step/g-ap214/Add_Tree.cpp: Rework the 'check
for problem objects' logic a bit more |
13:45.36 |
Notify |
03BRL-CAD:tbrowder2 * 59818
brlcad/trunk/src/libbu/tests/bu_bitv.c: make tests a little easier
to interpret |
13:45.39 |
Notify |
03BRL-CAD:starseeker * 59826
(brlcad/trunk/include/CMakeLists.txt brlcad/trunk/include/bu.h):
Set up bu include dir |
13:45.43 |
Notify |
03BRL-CAD:starseeker * 59822
(brlcad/trunk/src/conv/step/g-ap214/AP214e3.h
brlcad/trunk/src/conv/step/g-ap214/Add_Tree.cpp
brlcad/trunk/src/conv/step/g-ap214/G_Objects.cpp): Begin the work
of making the tree walk 'live' - i.e., actually generating step
entities. |
13:45.48 |
*** join/#brlcad luca79
(~luca@net-37-117-82-13.cust.vodafonedsl.it) |
13:45.48 |
Notify |
03BRL-CAD:starseeker * 59829
(brlcad/trunk/include/CMakeLists.txt brlcad/trunk/include/bu.h):
Break out vlb |
13:45.52 |
Notify |
03BRL-CAD:starseeker * 59840
(brlcad/trunk/src/conv/step/g-ap214/AP214e3.h
brlcad/trunk/src/conv/step/g-ap214/Add_Tree.cpp and 7 others):
Explose the manifold_solid_brep as well - will need it for
boolean_result |
13:45.54 |
Notify |
03BRL-CAD:tbrowder2 * 59817
brlcad/trunk/src/libbu/tests/CMakeLists.txt: split bu_vls tests
into an include file for ease of maintenance |
13:45.56 |
Notify |
03BRL-CAD:starseeker * 59830
(brlcad/trunk/include/CMakeLists.txt brlcad/trunk/include/bu.h):
Break conversion code into cv.h |
13:45.59 |
Notify |
03BRL-CAD:starseeker * 59832
(brlcad/trunk/include/CMakeLists.txt brlcad/trunk/include/bu.h
brlcad/trunk/include/nurb.h): Move magic.h to bu dir |
13:46.01 |
Notify |
03BRL-CAD:starseeker * 59835
(brlcad/trunk/include/CMakeLists.txt brlcad/trunk/include/bu.h):
Break out bitv from libbu |
13:46.03 |
Notify |
03BRL-CAD:starseeker * 59828
(brlcad/trunk/include/CMakeLists.txt brlcad/trunk/include/bu.h):
Break list code out into list.h |
13:46.05 |
Notify |
03BRL-CAD:starseeker * 59827
(brlcad/trunk/include/CMakeLists.txt brlcad/trunk/include/bu.h):
Break avs and vls out into individual .h files |
13:56.05 |
brlcad |
starseeker: the only danger with that approach
is that a header might happen to work if another header precedes it
... but then it still might not be properly encapsulated
itself |
13:56.47 |
*** join/#brlcad _caleb
(c318dc10@gateway/web/freenode/ip.195.24.220.16) |
13:57.35 |
mpictor |
starseeker: pretty sure they are BRep only.
IIRC, SALOME only converts to mesh immediately before running an
FEA tool. |
13:58.14 |
brlcad |
having those kinds of issues biting us
post-release are usually a little costly to deal with |
13:58.30 |
``Erik |
brlcad: can you verify that I'm not talking
out my arse with https://news.ycombinator.com/item?id=7224208
? the build did work and the equipment is what I said? |
13:59.26 |
brlcad |
_caleb: also note that our project ideas page
is going to change, get updated with a few more ideas |
13:59.37 |
brlcad |
a few completed ones will go away |
14:00.35 |
_caleb |
ok! so when will the new ideas be
posted? |
14:02.17 |
``Erik |
_caleb: you can propose new ideas, or you can
tell us what kinds of things you're interested in and we can come
up with ideas together :) |
14:02.33 |
brlcad |
``Erik: ahhh, huh -- that might be maths22 GCI
interface |
14:03.46 |
``Erik |
brlcad: I did some kill fu on quite a few of
them, but that's a temporary fix and the issue will
return... |
14:05.33 |
brlcad |
``Erik: close enough on the write-up |
14:06.00 |
brlcad |
cmake did run cleanly |
14:06.18 |
``Erik |
the build didn't work? |
14:06.49 |
brlcad |
yeah sources were another issue, mostly our
C++ code using features that gcc 2.95 didn't support |
14:07.08 |
brlcad |
code in src/other at that (re2c for
example) |
14:08.14 |
``Erik |
ah, hardly an issue with cmake, *shrug* the
counterpoint is undamaged, I think *shrug* :) |
14:08.23 |
brlcad |
still have to try mipspro with stl installed
and gcc3.3 |
14:08.34 |
brlcad |
suspect both will work mostly fine |
14:08.45 |
brlcad |
also, I think it's a 200mhz |
14:09.05 |
``Erik |
heh, tegtmeyers obj parser would probably stop
99% of "old" systems :) |
14:10.31 |
Notify |
03BRL-CAD:brlcad * 59843
brlcad/trunk/src/libbu/vls_vprintf.c: revert r58231 (unreverting
r58221) because it's wrong on many levels. this is inside a %s,
it's a width specifier, not octal, not hex, specifying
zero-padding. tom was right, just read the number. |
14:10.48 |
``Erik |
the gsoc git www issue is something we should
look at immediately, though... imho |
14:49.35 |
Notify |
03BRL-CAD:carlmoore * 59845
(brlcad/trunk/src/librt/primitives/nmg/nmg_fuse.c
brlcad/trunk/src/librt/primitives/nmg/nmg_inter.c): remove trailing
blanks/tabs, and change 'ourself' (which showed up in spellings) to
'ourselves' |
15:11.27 |
*** join/#brlcad FreezingCold
(~FreezingC@205.211.52.161) |
15:57.28 |
*** join/#brlcad FOSScookie
(~brian@107-200-34-31.lightspeed.tulsok.sbcglobal.net) |
15:59.50 |
Notify |
03BRL-CAD:brlcad * 59844
brlcad/trunk/src/libbu/tests/bu_vls_vprintf.c: retain the test, but
comment no longer necessary |
16:01.00 |
brlcad |
maths22: do you know where git-remote-https is
coming from? |
16:14.29 |
*** join/#brlcad luca79
(~luca@host207-17-dynamic.4-87-r.retail.telecomitalia.it) |
16:31.43 |
starseeker |
brlcad: so we need a manual review, or is
there an automated tool I can/should be using to confirm
encapsulation? |
16:38.08 |
starseeker |
mpictor: I don't suppose the boolean bits in
SALOME could be made into a small independent library? |
16:38.50 |
brlcad |
basks in the awesomeness
that is dtruss |
16:39.07 |
brlcad |
starseeker: the compiler will tell you to some
extent |
16:40.45 |
brlcad |
try: cd include/bu ; gcc -dP
defines.h |
16:41.03 |
brlcad |
that will succeed, then try vls.h |
16:41.17 |
brlcad |
you'll get a .gch (precompiled header) if it
passes |
16:41.55 |
brlcad |
it's a little more complex if the header
refers to headers in other dirs (avoid that for now) |
16:42.18 |
brlcad |
but you will probably need -I.. to get
common.h |
16:43.25 |
*** join/#brlcad devinder
(~devinder@202.164.53.117) |
16:44.04 |
starseeker |
brlcad: ok. Part of it is just that I hadn't
moved a few things to defines.h that I knew needed to be moved.
Let me do that quick, then I'll see what's still busted |
16:44.30 |
brlcad |
that frankly might make a good gsoc project,
not as easy as it seems |
16:45.23 |
starseeker |
brlcad: even if we can't yet assert that
headers in subdirs are 'stand alone' and everybody needs to still
use bu.h for everything, the readibility improvement is a
win |
16:47.51 |
``Erik |
heh, dtruss? a dtrace variant of the old
school bsd truss? :) |
16:48.42 |
Notify |
03BRL-CAD:starseeker * 59846
(brlcad/trunk/include/bu/defines.h brlcad/trunk/include/bu.h): Put
more of the common definions that should be in defines.h into
defines.h |
16:54.59 |
Notify |
03BRL-CAD:starseeker * 59847
(brlcad/trunk/include/bu/defines.h brlcad/trunk/include/bu.h): Move
genptr_t definition to bu/defines.h - part of me is include to just
remove this, since it was deprecated back in 7.16, but one thing at
a time. |
17:00.42 |
*** join/#brlcad FreezingCold
(~FreezingC@205.211.50.161) |
17:18.02 |
*** join/#brlcad caen23
(~caen23@92.81.213.198) |
17:26.54 |
Notify |
03BRL-CAD:starseeker * 59848
(brlcad/trunk/include/bu/avs.h brlcad/trunk/include/bu/bitv.h and 5
others): Using the gcc -dP test Sean suggested, make sure all the
headers have what they need to be self contained. I don't think we
want to use bio.h here (at a minimum, a definition of pipe in
librt's pipe.c conflicts when it is used) but need to make
sure. |
17:27.15 |
starseeker |
brlcad: I get gch files for all of the bu
headers now |
17:29.39 |
starseeker |
search.h in rt will take a little more time -
need to split out bu/ptbl.h and rt_wdb at a minimum, |
17:30.11 |
starseeker |
unless I go ahead and include all of bu.h in
the rt sub-headers, which I'm guessing is not ideal |
17:32.41 |
starseeker |
brlcad: that gch file thing might be a nifty
regression test to add, unless it's too compiler specific for you
to want to include it |
17:40.29 |
*** join/#brlcad luca79
(~luca@net-37-117-82-13.cust.vodafonedsl.it) |
17:44.13 |
starseeker |
looks like the clang version would be clang
-I.. -dP -Qunused-arguments |
17:44.23 |
starseeker |
vs gcc -I.. -dP |
17:44.32 |
starseeker |
both generate a gch file |
17:57.11 |
*** join/#brlcad ejno
(~ejno@unaffiliated/kazaik) |
18:21.23 |
*** join/#brlcad FreezingCold
(~FreezingC@205.211.50.163) |
18:23.50 |
*** join/#brlcad FOSScookie
(~brian@107-200-34-31.lightspeed.tulsok.sbcglobal.net) |
18:54.01 |
*** join/#brlcad FreezingCold
(~FreezingC@205.211.54.163) |
19:11.57 |
brlcad |
starseeker: looking better .. though "stdio.h"
isn't right |
19:12.07 |
brlcad |
sys headers are always <> |
19:12.22 |
brlcad |
and we don't need bio.h for just
FILE |
19:17.35 |
*** join/#brlcad n_reed
(~molto_cre@66-118-151-70.static.sagonet.net) |
19:17.40 |
*** join/#brlcad hickoryknoll
(~hickorykn@66-118-151-70.static.sagonet.net) |
19:17.40 |
*** join/#brlcad starseeker
(~starseeke@66-118-151-70.static.sagonet.net) |
19:17.51 |
*** join/#brlcad Ch3ck
(~Ch3ck@66-118-151-70.static.sagonet.net) |
19:22.39 |
*** join/#brlcad maths22
(~gcimaths@66-118-151-70.static.sagonet.net) |
19:22.40 |
*** join/#brlcad ejno
(~ejno@unaffiliated/kazaik) |
19:24.31 |
*** join/#brlcad FreezingCold
(~FreezingC@205.211.52.163) |
19:55.42 |
Notify |
03BRL-CAD:tbrowder2 * 59849
brlcad/trunk/src/libbu/tests/bu_vls_vprintf.c: change test 66 to
one that is POSIX defined; use CTEST_* macros to clarify test
results |
20:08.59 |
Notify |
03BRL-CAD:starseeker * 59850
(brlcad/trunk/include/bu/vlb.h brlcad/trunk/include/bu/vls.h): Fix
stdio include and comment - definitely not using bio.h for
this |
20:12.09 |
mpictor |
starseeker: I don't know but I think I know a
couple people who can give an answer |
20:22.07 |
Notify |
03BRL-CAD:tbrowder2 * 59851
brlcad/trunk/src/libbu/tests/CMakeLists.txt: simplify adding
vls_vprintf tests (could do others easily if we remove
comments) |
20:42.09 |
Notify |
03BRL-CAD:starseeker * 59852
(brlcad/trunk/include/bu/avs.h brlcad/trunk/include/bu/bitv.h and 3
others): Make sure magic numbers are available. |
20:42.41 |
Notify |
03BRL-CAD:starseeker * 59853
(brlcad/trunk/include/CMakeLists.txt brlcad/trunk/include/bu.h):
Break out ptbl from bu.h |
20:43.06 |
brlcad |
they all use magic? |
20:46.07 |
Notify |
03BRL-CAD:n_reed * 59854
brlcad/trunk/src/libbu/tests/CMakeLists.txt: ignoring non-existent
file |
20:47.48 |
Notify |
03BRL-CAD:starseeker * 59855
brlcad/trunk/include/rt/search.h: Add a few basics to search.h -
need struct rt_wdb, struct db_i and struct directory broken
out |
20:51.09 |
brlcad |
starseeker: I think we can cleanly get away
with just "dir/header.h" instead of relative paths since we already
search our include dir |
20:51.33 |
starseeker |
brlcad: rt_wdb and db_i both reference each
other - how do I break them out? |
20:51.33 |
*** join/#brlcad merzo
(~merzo@185-114-133-95.pool.ukrtel.net) |
20:51.34 |
brlcad |
simplifies things a little bit and avoids
implicitly requiring them to reside next to each other |
20:52.44 |
Notify |
03BRL-CAD:starseeker * 59856
brlcad/trunk/include/rt/search.h: Don't do relative parent path for
bu headers. |
20:54.18 |
starseeker |
brlcad: fixed |
20:54.51 |
starseeker |
(good point about not requiring relative
locations) |
20:55.03 |
starseeker |
bbiab |
21:13.52 |
brlcad |
same for defines.h |
21:23.03 |
Notify |
03BRL-CAD:tbrowder2 * 59857
brlcad/trunk/src/libbu/tests/CMakeLists.txt: go ahead and simplify
other tests (the test source files also have the comments so they
shouldn't be missed) |
21:26.41 |
*** join/#brlcad Anaphaxeton
(~george@unaffiliated/anaphaxeton) |
21:38.33 |
*** join/#brlcad FreezingCold
(~FreezingC@135.0.41.14) |
22:13.36 |
n_reed |
http://www.chrisj.com.au/ |
22:13.59 |
starseeker |
brlcad: for defines.h - don't we want to make
sure libbu is getting the libbu defines.h and not the librt
version? |
22:14.14 |
starseeker |
or should we use a prefix, e.g.
bu_defines.h? |
22:18.11 |
Notify |
03BRL-CAD:starseeker * 59858
(brlcad/trunk/include/bu/avs.h brlcad/trunk/include/bu/bitv.h and 6
others): Use bu_defines rather than a generic 'defines.h' for
clarity. |
22:19.01 |
Notify |
03BRL-CAD:starseeker * 59859
(brlcad/trunk/include/CMakeLists.txt
brlcad/trunk/include/bu/bu_defines.h): Update cmake and
header |
22:19.33 |
starseeker |
sees he needs to build up to
librt - will need a lot of libbu and libbn stuff |
22:21.41 |
Notify |
03BRL-CAD:starseeker * 59860
brlcad/trunk/include/bu.h: Don't forget bu.h |
22:25.12 |
Notify |
03BRL-CAD:starseeker * 59861
(brlcad/trunk/include/CMakeLists.txt brlcad/trunk/include/bu/avs.h
and 9 others): Actually, given the right include path, the
directory *is* the prefix. revert, try again... |
22:29.04 |
Notify |
03BRL-CAD:starseeker * 59862
(brlcad/trunk/include/bu/avs.h brlcad/trunk/include/bu/bitv.h and 6
others): There we go - just use the dir prefix at all
times. |
22:59.45 |
*** join/#brlcad Anaphaxeton
(~george@unaffiliated/anaphaxeton) |
23:22.17 |
*** join/#brlcad merzo
(~merzo@152-6-132-95.pool.ukrtel.net) |
23:35.48 |
starseeker |
humph. tetgen finally opted to adopt a
standard open source license, and went with the Affero
GPLv3 |