[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [libredwg] contributions v1.2 available
From: |
Thien-Thi Nguyen |
Subject: |
Re: [libredwg] contributions v1.2 available |
Date: |
Mon, 22 Feb 2010 09:47:15 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.1.91 (gnu/linux) |
() Rodrigo Rodrigues da Silva <address@hidden>
() Sun, 21 Feb 2010 21:03:46 -0300
Thanks for your job. I think we can give you write access if nobody
objects it. Just do any dirty stuff in a branch =D
Cool. OK.
> v2 -- add "configure --enable-tracing"
Check the src/logging.h. This simple logging framework allows
different loglevels for different files. I was thinking about
--enable-tracing or --enable-log --loglevel=x (#defines inside the
files would override the default to allow fine log tuning -- maybe
this fine tuning will not useful at all)
Thanks for the pointers. I have a v2 ready to push (to gnuvola) for
review -- will do so in the next couple hours. I will explain it in
detail in the announcement.
> - What are the version numbering schemes for LibreDWG?
> - repository tags
> - project version
> - shared-object library version
There's no clear policy yet. The only thing we know is that the first
release will be 0.4 (in homage to libdwg which died after 0.3).
Nice touch.
But there is a rough roadmap somewhere in the wiki. 1.0 means:
"stable" + R13-R2007 read support + C (at least) API. 2.0 means
stable write support (if we ever get there). I think we are taking
too long to release.
No worries. I expect in the next couple weeks that we'll be able to
do "make all check install installcheck dist distcheck", at which point
making a nightly/weekly alpha release will be push-button affair.
Maybe we should set some milestones or blocker bugs to release at
least a beta. There is many people interested in LibreDWG, but not
having a release makes it seem untrustworthy.
I would caution against the label "beta" until 0.9 or so.
> - Should "configure --enable-tracing" be yes or no by default?
No. A library should not output any text by default.
OK, thanks for the clarification.
> - What is the criteria for declaring a stable API (for bindings)?
Good question. But something like: we are able to write a dwg2foo
converter (or maybe an importing module for a software like grass -
I'm doing that) without having to access the dwg struct directly -
things like
dwg->tio.object->tio.BLK_HDR->inserts->tio.object->tio.INSERT->....
OK.
> - What is the documentation strategy (doxygen, hand-write, ...)?
When we joined the GNU project we told the evaluators that we would
think about docs before releasing a stable version. Maybe we should
start thinking about this. The default documentation format for the
GNU project is TeXinfo IIRC. Can doxygen generate TeXinfo files?
Yes, texinfo is the standard GNU way. Probably the best approach for
reference documentation is to use a texinfo skeleton and include bits
extracted from comments in the source code. I don't know too much about
doxygen, but surely it can do the extraction.
It's a question of comfort and familiarity -- some people like the
structure and ease of a particular tool, while others don't like the
same tool's limitations and restrictions. Perhaps a regular doxygen
user can speak up about it?
In any case, i'll be glad to write the texinfo skeleton unless someone
else beats me to it.
BTW, why all those distcheck installcheck (make dist seems ok)?
The more problems we find, earlier, the less problems we (and users)
will have, later. These techniques are standardized ways to isolate and
address certain classes of problems. They are tools for a clean process,
like "gcc -Wall -Wextra" is a tool for clean code.
thi