On Wed, Aug 7, 2013 at 10:23 PM, Christopher Sean Morrison
<brl...@mac.com>wrote:
>
> On Aug 7, 2013, at 8:54 PM, Tom Browder wrote:
>
> > Hm, how's it problematic, Cliff, I've used Perl on Windows a fair
> > amount? (Maybe I need to change languages!)
>
Er, sorry - I wasn't precise enough. Not problematic from a technical
perspective (that I know of) but it's a non-standard tool on Windows and
that can make it hard for people to get installed depending on their local
environment.
You don't need to switch if you're comfortable in Perl, Tom - certainly not
for the initial development stages. It's only when we reach the point that
we have a technique that is required to work or man pages in DocBook won't
be available that it becomes a concern, and that'll be up to me to deal
with since I'm the one trying to minimize the BRL-CAD external dependency
tree. The earlier DocBook work you did was really excellent, and that
started out in Perl - I certainly don't want the issue of language
selection to discourage you from doing more of that calibre of work for the
project!
> Not to speak for him, but there would be an issue to require perl if only
> because it's not necessarily available on a new target system (even some
> linux/bsd/unix). Sure it could be installed, but we just invested a ton of
> effort to get the build fully encapsulated even going so far as to rewrite
> shell scripts and parser code so we don't have to depend on sh, flex, and
> yacc.
>
> It's (finally) to the point where we literally just have two requirements
> to build everything now: cmake and a compilation framework. A part of me
> even wants to include a minimally bootstrapped cmake so that there really
> is nothing one must download and pre-install. It's an ideal we used to
> adhere to strictly, but have become idle about in recent years.
>
Precisely.
> I don't think there's a problem using perl and other facilities when
> they're detected as long as we gracefully handle them not existing as well.
It sounds like the end result here would be "no Perl, no man pages." Ouch.
> Still, this is really a majorly beneficial undertaking so lets keep this
> dialog going. I don't think anything is set in stone.
>
Is this something that Tcl could handle? We already guarantee as part of
the BRL-CAD build that we have tclsh available, although I suppose it's not
in Perl's league for text processing...
Again Tom, don't let me discourage you - the main reason I mentioned it was
your README document specifically called out Perl, and I would expect the
*final* iteration of the system to be in CMake or Tcl (Tcl is probably
ideal, if it can do it without too much ugly, since Tcl will almost
certainly survive much longer in BRL-CAD than the CMake logic will...)
CY
------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
_______________________________________________
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel
