0.12b

.gitignore

@@ -1,2 +1,2 @@
-TODO.md
-OLD
+TODO
+*.new

Makefile

@@ -1,12 +1,14 @@
-SHELL	:= /bin/bash	
-PATH	:= $(PATH):UTIL
 PACKAGE	:= subrelease
-VERSION	:= 0.11
+VERSION	:= 0.12
 PROJECT	:= makeutils
 AUTHORS	:= R.Jaksa 2001,2021,2023 GPLv3
-CAPTION := minimal subrelease snapshotting
-SUBVERS	:= 
-BUILT	:= $(shell echo `date +%Y-%m-%d`)
+CAPTION := directory to package snapshotting
+SUBVERS	:= b
+
+SHELL	:= /bin/bash
+PATH	:= usr/bin:$(PATH)
+PKGNAME	:= $(PACKAGE)-$(VERSION)$(SUBVERSION)
+DATE	:= $(shell date '+%Y-%m-%d')
 
 BIN := getversion subrelease
 SRC := $(BIN:%=%.pl)
@@ -17,8 +19,9 @@ LIB := $(filter-out $(SRC),$(LIB))
 all: $(BIN) $(DOC)
 
 %: %.pl $(LIB) .version.pl .built.%.pl Makefile
-	@echo -e '#!/usr/bin/perl\n' > $@
-	perlpp-simple $< >> $@
+	@echo -e '#!/usr/bin/perl' > $@
+	@echo "# $@ generated from $(PKGNAME)/$< $(DATE)" >> $@
+	pcpp $< >> $@
 	@chmod 755 $@
 
 .version.pl: Makefile
@@ -31,20 +34,23 @@ all: $(BIN) $(DOC)
 
 .PRECIOUS: .built.%.pl
 .built.%.pl: %.pl $(LIB) .version.pl Makefile
-	@echo 'our $$BUILT = "$(BUILT)";' > $@
+	@echo 'our $$BUILT = "$(DATE)";' > $@
 	@echo "update $@"
 
-# install symlinks to private ~/bin
-install: $(BIN) subls
-	@echo install symlinks to ~/bin:
-	@mkdir -p ~/bin
-	@for i in $+; do ln -sf `pwd`/$$i ~/bin/`basename $$i`; done
-	@for i in $+; do ls -l --color ~/bin/`basename $$i`; done
-	@if test ! `echo $$PATH | grep ~/bin`; then echo "~/bin missing in your PATH: $$PATH"; fi
-
 $(DOC): doc/%.md: % | doc
 	$< -h | man2md > $@
 
+# /map install (also subls)
+ifneq ($(wildcard /map),)
+install: $(BIN) subls
+	mapinstall -v /box/$(PROJECT)/$(PKGNAME) /map/$(PACKAGE) bin $^
+
+# /usr/local install
+else
+install: $(BIN)
+	install $^ /usr/local/bin
+endif
+
 clean:
 	rm -f .version.pl
 	rm -f .built.*.pl
@@ -53,4 +59,4 @@ mrproper: clean
 	rm -f $(BIN)
 	rm -f $(DOC)
 
-include ~/.gitlab/Makefile.git
+-include ~/.github/Makefile.git

NEWS

@@ -1,3 +1,5 @@
+0.12  - fixed Makefile, install to /usr/local
+      - added EXCLUDE
 0.11  - version up to the mkdist 0.8...
 0.2   - code cleanup
       - getversion uses next.pl

README.md

@@ -1,17 +1,16 @@
-
 # subrelease
 
-Simple tool to snapshot current directory to the package file or into
+Simple tool to snapshot the current directory to the package file or into
 subrelease archive.
 
 #### Story
 
-I have used a packing script since around 2000.  First it was a few lines shell
-script, later a big one with html generator, now small again.  I still use it
+I have used a packing script since around 2000.  First, it was a few lines of shell
+script, later a big one with html generator, and now small again.  I still use it
 today, even alongside git.
 
 The inspiration came when somebody told me that compressing a file once or
-ten-times is the same.
+ten times is the same.
 
 ![](doc/size.png) <!--[![](doc/size.png)](doc/size.csv)-->
 
@@ -21,16 +20,16 @@ The hit-enter usage is: `subrelease`, `subrelease`, `subrelease`, increment vers
 `subrelease`, `subrelease`...
 
 This is a sequence of several 'small' subreleases which are handled
-automatically, then a 'big' release, then next round of subreleases etc.  If it
-is git, it would be a sequence of commits, then tag (plus release), and next
+automatically, then a 'big' release, then the next round of subreleases, etc.  If it
+is git, it would be a sequence of commits, then tag (plus release), and the next
 round of commits.  When subrelease is used over the git repository, subreleases
-are completely independent from the git.
+are completely independent of the git.
 
 Subrelease itself does:
 
-1. identifies package name, version, subversion and location of archive files (automatically),
+1. identifies package name, version, subversion, and location of archive files (automatically),
 2. identifies whether now it should be a subrelease or release (automatically),
-3. saves package snapshot into archive or a release file (automatically),
+3. saves package snapshot into an archive or a release file (automatically),
 4. increments subrelease variable value if needed (automatically).
 
 <!-- ![](doc/sshot.png)-->
@@ -45,7 +44,7 @@ Subrelease saves two types of files:
 
 The `.tlz` and `.xlz` are shortcuts for `.tar.lz` and can be extracted with
 standard tar.  Optionally, subrelease can save `.tar.gz`, `.tbz2`, `.tar.zst`,
-etc.  All these files are saved into parent directory, or into `../tgz` directory
+etc.  All these files are saved into the parent directory, or the `../tgz` directory
 if it exists.
 
 Typical subrelease history and saved files would be:
@@ -55,35 +54,35 @@ Typical subrelease history and saved files would be:
 
 #### Variants
 
-Subrelease can archive variants of a package, for instance the "beta" variant,
-or David's variant "david" etc.  To create a beta variant of package, just set
-a flag `VARIANT` to "beta" (when you increment a version).  Later when you
+Subrelease can archive variants of a package, for instance, the "beta" variant,
+or David's variant "david" etc.  To create a beta variant of the package, just set
+the flag `VARIANT` to "beta" (when you increment a version).  Later when you
 decide to turn off beta status, just remove the flag and call the subrelease.
 You will have beta release and main release packages, and a common archive for
 beta and main subreleases:
 
 <!-- ![](doc/beta.png)-->
 <img src=doc/beta.png/ width=720px>
 
-Variants flags can be used to create temporary experimental variants of package
-to be eventually merged-back later.  In following example we copy the
-subversion b of package to different directory and set a variant flag on it.
-Then on the next subrelease call we got local initial release of variant
-"david", and on the second call a subversions archive is created and initiated
+Variant flags can be used to create temporary experimental variants of the package
+to be eventually merged back later.  In the following example, we copy the
+subversion b of the package to a different directory and set a variant flag on it.
+Then on the next subrelease call, we got the local initial release of the variant
+"david", and on the second call, a subversion archive is created and initiated
 with a new subrelease c.  This subrelease c and the main package subrelease c are
 different.  Archives are different as well, although having the same name.
 
 <!-- ![](doc/branch.png)-->
 <img src=doc/branch.png/ width=720px>
 
-Archive names do not contain variant string, to allow to freely change variant
+Archive names do not contain a variant string, to allow to freely change the variant
 string from subversion to subversion.
 
 #### Reserved names
 
-In order to use the same version name by the subrelease and by the application,
+To use the same version name by the subrelease and by the application,
 subrelease has to understand variable definition in particular programming
-language, and we have to reserve few variable names, like this for C:
+language, and we have to reserve a few variable names, like this for C:
 
 ``` c
 # define PACKAGE "package-name"
@@ -103,14 +102,14 @@ $COPYLEFT="(c) The.Author 1999, GPL";
 
 Accompanying script `getversion` can inspect these reserved variables.  It
 checks `VERSION.h` or `CONFIG.h` files, or `VERSION.pl`, `VERSION.py`, etc. for
-other languages.  See [`getversion -h`](doc/getversion.md) for description of
-syntax for other languages.
+other languages.  See [`getversion -h`](doc/getversion.md) for a description of
+the syntax for other languages.
 
 For multi-language applications, the `Makefile` can be used to hold variables,
 which when changed will write them to temporary files for every used language,
 like `.version.pl`, `.version.py`, etc.
 
-Reserved variables names are (plus few more for config files):
+Reserved variable names are (plus a few more for config files):
 
 &emsp; `PACKAGE` package name,  
 &emsp; `VERSION` its version,  
@@ -120,43 +119,51 @@ Reserved variables names are (plus few more for config files):
 &emsp; `CAPTION` any package notes, message, definition,  
 &emsp; `VARIANT` `BRANCH` variant/branch name.  
 
-The `SUBVERSION` variable is automatically incremented always when subversion
+The `SUBVERSION` variable is automatically incremented always when the subversion
 creates a new subrelease, thus the application can know which subversion it is.
 
 #### Config files
 
-Stealth operation without introducing any new variables definitions to the
+Stealth operation without introducing any new variable definitions to the
 source tree is possible by keeping them instead in the config file
-`.subrelease` in current or any parent directory (than you will not add
-anything into source tree).
+`.subrelease` in the current or any parent directory (than you will not add
+anything into the source tree).
 
-Config files also recognize few more variables.  To preserve the namespace of
+Config files also recognize a few more variables.  To preserve the namespace of
 application code these are config-files only, visible only in `.subrelease` or
 `VERSION` files:
 
 &emsp; `SUFFIX` the archive suffix, see [`subrelease -h`](doc/subrelease.md) for the list of suffixes,  
 &emsp; `TGZDIR` target directory, instead of the default `../tgz` or `..`,  
+&emsp; `EXCLUDE` exclude specified files from being archived,  
 &emsp; `ALWAYS` the script/command to be fired at the and of every `subrelease` run,  
 &emsp; `ONREL` `ONRELEASE`  script only fired at full release,  
 &emsp; `ONSUB` `ONSUBRELEASE`  only fired at the subrelease, not at release.  
 
 Scripts can be used to automatically:
 
  * to sync data to mirror,
- * to submit summary to webpage,
+ * to submit a summary to a webpage,
  * to run code metrics scripts,
  * etc.
 
-The `.subrelease` can be found in home directory, current directory or any
+The `EXCLUDE` can be used to avoid `.git` subdirs in all project directories by
+placing the `.subrelease` file in the top-level projects directory with a line:
+
+```
+EXCLUDE: .git
+```
+
+The `.subrelease` can be placed in the home directory, current directory, or any
 parent directory.  The order of variables overriding is:
 
- 1. `~/.subrelease` from home directory,
- 2. `./.subrelease` or `../.subrelease` or higher, varibles here override these from 1.,
- 3. CLI arguments, like `-v` option overrides config values, step 4. depends on its value,
+ 1. `~/.subrelease` from the home directory,
+ 2. `./.subrelease` or `../.subrelease` or higher, variables here override these from 1.,
+ 3. CLI arguments, like `-v` option override config values, step 4. depends on its value,
  4. `./VERSION.c` or `./VERSION.pl` etc., these are main variables definitions, override 1. to 3.,
- 5. CLI arguments, finaly CLI again overrides everything.
+ 5. CLI arguments, finally CLI again overrides everything.
 
-Some variables can be defined is `.subrelease` file and some in `VERSION.c`
+Some variables can be defined in the `.subrelease` file and some in the `VERSION.c`
 file etc. at the same time, to control their visibility.
 
 #### See also
@@ -172,24 +179,24 @@ installation the `make install` routine is provided.
 
 #### Under the hood
 
-Subrelease is written in perl, but is compiled from source files to the final
-executable script by preprocessor.  The reason for such approach is to have
-singlefile script as a result, and at the same time allow source code to be
-structured to several files.  Perl provides best expressive power and great
+Subrelease is written in perl but is compiled from source files to the final
+executable script by preprocessor.  The reason for such an approach is to have
+a singlefile script as a result, and at the same time allow source code to be
+structured to several files.  Perl provides the best expressive power and great
 stability, which is (most) important for the maintenance of script in the long
-term.  And for compactness of executed application script.
+term.  And for compactness of the executed application script.
 
-Over the time I had different requirements for the script.  Sometimes conflicting.
-Today my subrelease design summary would be:
+Over time I had different requirements for the script.  Sometimes conflicting.
+Today my subrelease design summary will be:
 
  * content-only approach without script's private metadata/database/indexes:
    - primary knowledge source - filenames in the archive,
    - secondary knowledge source - variables in the application source code (and configs),
  * data access with standard tools - `subrelease` is not needed to extract or inspect the archive,
- * autodetection first - autodetect everything what is possible to autodetect,
+ * autodetection first - autodetect everything possible to autodetect,
  * any-functionality = single-command:
    - `subrelease` to archive,
    - `getversion` to inspect,
- * can be used either as standalone release tool, or alongside git/github etc.
+ * can be used either as a standalone release tool or alongside git/github etc.
 
 <br><div align=right><i>R.Jaksa 2023</i></div>