Il 30/05/2013 08:55, Ulrik Sandborg-Petersen ha scritto:
>> 1) why not moving autogen.sh, rmfiles.sh and valgrind.sh in a maintainance/
>> directory?
>
> I would actually advocate keeping them in the root directory for the
> following reasons:
>
> 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".
> b) rmfiles.sh could be moved, but it is a script which is run
> frequently, and it is easier (IMHO) to run "./rm" + tab rater than
> "./maint" + tab + "rm" + tab :-).
If you really run it frequently and you are using bash, you can also run it by
mean of backward search in your history:
Ctrl+r + <part of the command that matches> (e.g., "e/r" or "/r" should be
enough).
I do not think it is much harder then "./rm" + tab
Unless we want to distribute rmfiles.sh and autogen.sh I still advocate moving
them in a maintainance directory.
> c) That would leave valgrind.sh as the only script to be moved. As
> William of Ockham has famously said, "do not multiply categories beyond
> necessity". That means, in this case, I think we should postpone adding
> another directory (with another Makefile.am) until we have more scripts
> that actually need to go there.
I completely agree on this point. If the other scripts are not moving,
valgrind.sh should not be moved as well.
> What do you both think? I am open to arguments to the contrary :-).
>
>> 2) regarding rmfiles.sh: why not making use of "make distclean" in it, so
>> that we can also check that the clean and distclean target are working
>> properly? If it is ok with
>> you, I can upload an updated version of this script.
>
> I hadn't actually thought about that, but it is true: I always run "make
> distclean" before I run rmfiles.sh. The rmfiles.sh script is really not
> useful before a make distclean, only after it.
Uploaded the script.
Regarding bash scripts, I noticed that you used "#!/bin/bash" instead of
"#!/bin/sh".
I recommend to use "#!/bin/sh" when the script can run under a standard shell
and do not require bash. Bash usually brings a "big" startup and memory
overhead.
To check if your script can run using a standard shell, you can use the
"checkbashisms" tool.
> 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. :-)
Bests,
Giulio.
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/acopost-devel
