Hello to you both,
I answer inline below.
On 05/30/2013 02:31 PM, Tiago Tresoldi wrote:
In reply to both Ulrik and Giulio
> a) autogen.sh is traditionally placed in the root directory. I have
> seen it in lots of packages, and always in the root of the sources.
I agree, but it used to be harder in the past to recreate autoconf
files than just "autoreconf --install".
I thought the purpose behind rmfiles.sh was to clean the entire tree
of files more related to active development than to distribution, such
as logs and the like, resulting in a clearer autogen/configure/makefiles.
Just to be clear about the original idea: The rmfiles script was
originally meant to clean the working directory (after a make distclean,
possibly a failed make distclean) of any remaining files that were not
supposed to be under source code control because they were generated.
I think it is time to plan the final tree structure, this organic
growth is starting to get confusing. I suppose drawing a directory
structure, agreeing on it and implementing it is a priority at this
time. Having read what has been discussed, I would go for this:
/bin -- the compiled programs (do you think it is better to have them
in /src?) and the user scripts, with their extensions removed (using,
at least for now, the Perl ones)
I think the /bin directory should not contain the compiled programs, but
only the scripts. I don't think the Makefile.am in src/ copies the
compiled programs to /bin any more.
If we decide to have only scripts in there, why not call it /scripts
instead of /bin? The directory name "scripts" is, at least in my
experience, a commonly seen name for a directory containing scripts.
/doc -- nothing changes
/data -- default files (tbt and et rules)
/data/{language} -- pre-trained models, such as Marco Baroni's Italian
and Ulrik's pre-1948 Danish; as a complete set of trained models is
not complex, everything should ideally be kept in a single directory
Agreed.
/maintain -- development&debug scripts, C testing, etc.
/maintain/data -- data for testing, fake language corpus and
eventually its pre-trained models, etc.
Why not call it /test and simply have tests in there? That way, the
purpose of the directory is clear by its name.
I believe we have so few development scripts (valgrind.sh, rmfiles.sh,
autogen.sh) that they might as well stay in the root directory. But
again, I am not going to be dogmatic about this.
/src -- should only keep the source of the distributed programs;
acopost_test should be moved to /maintain
Before we move acopost_test.c, we need to think it through carefully.
Moving acopost_test.c to a different directory would entail:
1) Having to
a) #include files with -I../src in the /test (or /maintain) directory,
or else
b) move all headers to an /include directory.
2) Having to create a convenience library, src/libacopost.a, which
acopost_test.o could link against, with the .o files being tested.
What do you think? Is this complexity worth the clarity/purity that
comes from moving acopost_test.c?
I am not advocating either way at this point. Just mentioning some caveats.
> On a meta-note: This is the first Open Source project in which I
> participate as a an active co-developer rather than being
either: a) the
> sole developer or b) a "passive" guidance-factor. I am really
enjoying
> the interaction, and I wish to thank you both.
>
> On a related meta-note: I am also enjoying how you two are
pulling in
> the good direction of consensus on the mailinglist before
decisions are
> made. I must confess that, having been the sole developer on my
Open
> Source projects for 12 years, I do find it a good and worthwhile
> exercise to reach consensus, but I must exercise some restraint
in not
> just developing rather than seeking consensus before developing.
Thank
> you for your patience -- I promise to learn to communicate
rather than
> just decide in isolation.
Ideally we should all setup our own "public" repository, develop
there and merge into the main repository after consensus.
For a project of the current size of acopost, is probably
overkilling, but we should think about that for the future.
Given the current size of acopost and the available resources,
however, I think you should not stress yourself too much on ALWAYS
trying to seek consensus BEFORE
developing, or you will not be able to develop anything. An
informative note is appreciated. :-)
I share Ulrik's experience, it has been great! :)
I suppose the seek-for-consensus will not be so imposing after a
while; we are after all making some big changes for a project the size
of acopost, moving from a good old academic experience (by Ingo) made
compilable again after a decade (by a not-so-competent me) and fixed
by a third person (Ulrik) into a true open source project with Debian
packaging as one of its goals.
That is why I agree that we shold not really stress about seeking
consensus, and in my case I want you both to feel completely free to
"correct" my commits and then just drop a note. After all, this is
active development and git does it fine.
Agreed on all points.
Best,
Ulrik
------------------------------------------------------------------------------
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
_______________________________________________
acopost-devel mailing list
acopost-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acopost-devel
