litbuild 1.0.1 → 1.0.2

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 5e5f97c8713b5ce5f416800f73b0b77dd26321356514b436720ffc44b883297b
-  data.tar.gz: cc17ddf34f292be8da19eda5370abed391904c6dffe86318786b5629d140ecb3
+  metadata.gz: 4cc983f70c85f96dd03544d804f4c5971a55d401799209fbbfccdab244de6c28
+  data.tar.gz: 0e0dd20d35dd4565daff7ced67a1cf5e17a0394739a313042350c61e52ee4250
 SHA512:
-  metadata.gz: 2ee385855edbe3468a30d9a9cc2f75db9d0711634e5d7d3cf0916cd04d6ab6ec8d8673c04b035c715ceeb5ba5ac6d5afcacb958c96f925557710cb041cf46ab8
-  data.tar.gz: 614310bea2b03889d74c98fdcdd5789d388fe9830842ada60bf8d8efcb901a538b2fd61c2ae86aa873e6dfeaddda19e9bad3510c506da491c7e7285d55cc3036
+  metadata.gz: 16a83a065cd551c5a0e5adb179305097a663bdf09c5c436245206232897a4f754c922faf42df656f81e2a083a5c9c8182689602644d6c69a8999bfc7d7791909
+  data.tar.gz: 2b5f178c9c2343bd5a05e9874ca8e4076a21ec3a0acd7964f85e3cab5419c37b8c4f9306b8aafe7b2658e9170097afd6a113fe4ea80eae6928b1b223e63c92c6

checksums.yaml.gz.sig

@@ -1 +1,3 @@
-9�(Bę�O9N���lz����ݹH�8�`�����.�}IKuש�1����ky7Z$&`���S�se��}�����fF�P(D���*�kP�Z,�\s�M
+�n4��5�*�fa�
+j�m�r�{ic�K�y���pXu[񝨞{�NU�q{O�ʒj	
��I���H�X��&����:��L�Z�֢$���P7/�ij��$�ߴ���Ů	�H0��R�F3�Ђ��CZkȋ��=��6X�V���er#�~"�5�����)�wU��m��J��?�Q�
����4��Z6D
+�[�.�rNҨ�m�e��^�"��@T�l����Gw&%ȷa��=�8�ve�Y7�d��z0Q�E����.�p���4�c����B����

data/README

@@ -17,7 +17,7 @@ narrative.
 
 Automated build tools -- such as make, maven, and jam -- are great,
 because they allow developers on a project to focus their attention on
-the project codebase _per se_, and let the build system worry about how
+the project codebase _per se,_ and let the build system worry about how
 to compile and test it. There are lots of build tools, reflecting a wide
 variety of design goals and value systems. Regardless of which tool is
 used, though, I have noticed that once a software project reaches a
@@ -51,14 +51,16 @@ program), or you can run it through a `weave` program that produces
 document source (which you can send through a typesetting system like
 TeX or Docbook).
 
-Litbuild takes, as input, human-readable files -- referred to as
-"blueprints" -- that consist of narrative text interspersed with command
-blocks and other directives, just like the literate source in WEB and
-CWEB. It has a simpler interface, though: when litbuild is run, it
-always generates both a set of bash scripts that automate the actual
-build process and _also_ AsciiDoc-formatted documentation files that can
-be run through a document production toolchain to produce HTML or
-Docbook or some other documentation format.
+Litbuild is essentially a processor for a domain-specific language. It
+takes, as input, human-readable files -- referred to as "blueprints" --
+that consist of narrative text written with AsciiDoc markup,
+interspersed with command blocks and other directives, just like the
+literate source in WEB and CWEB. Litbuild has a simpler interface,
+though: when it is run, it always generates both a set of bash scripts
+that will execute the actual build process and _also_ AsciiDoc-formatted
+documentation files that can be run through a document production
+toolchain to produce HTML or PDF or whatever other documentation format
+you wish.
 
 The vision of litbuild is that, from a set of blueprints, you should be
 able to say:
@@ -90,7 +92,8 @@ Blueprints can refer to parameterized values. It is expected that
 default values for all these parameters will be provided (by convention,
 I generally put all the default values into a "configuration" narrative
 blueprint). To override any parameter value from the default, set an
-environment variable before running the `lb` driver program.
+environment variable with its name before running the `lb` driver
+program.
 
 To use the lb driver to build a complete cross-toolchain as part of the
 Cross-Building Linux process, for example, you might use something like:
@@ -107,7 +110,7 @@ for any situation where the various components of a build story need to
 have an overall framing narrative or discussion to make them
 comprehensible, or when all the parts of a build need to share a common
 configuration or environment -- which is the case for most complicated
-processes!
+processes.
 
 Debugging Blueprints
 ====================

data/lib/litbuild/bash_script_visitor.rb

@@ -73,6 +73,7 @@ module Litbuild
       section_dir = File.join(cwd, section.name)
       write(blueprint: section, location: cwd) do |script|
         render_restart_header(script, section.name)
+        FileUtils.mkdir_p(section_dir)
         script.puts("cd $(dirname $0)/#{section.name}")
         skip_line(script)
         write_components(location: section_dir, script: script)

data/lib/litbuild/version.rb

@@ -1,5 +1,5 @@
 # frozen_string_literal: true
 
 module Litbuild
-  VERSION = '1.0.1'
+  VERSION = '1.0.2'
 end

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: litbuild
 version: !ruby/object:Gem::Version
-  version: 1.0.1
+  version: 1.0.2
 platform: ruby
 authors:
 - Brett Neumeier
@@ -34,7 +34,7 @@ cert_chain:
   PvrrfEkjwo+u4dPBTaO5ZBa4qsFE5bK/1l6d4AVV5Yi5NohUwmpp1bFFCGPqvzVA
   bhee2x0YS1uGTnADpv2GLkmNMIA=
   -----END CERTIFICATE-----
-date: 2019-09-01 00:00:00.000000000 Z
+date: 2019-09-05 00:00:00.000000000 Z
 dependencies: []
 description: A build system based on Knuth's idea of literate programming.
 email:
@@ -80,7 +80,7 @@ required_ruby_version: !ruby/object:Gem::Requirement
   requirements:
   - - ">="
     - !ruby/object:Gem::Version
-      version: '2.5'
+      version: '2.6'
 required_rubygems_version: !ruby/object:Gem::Requirement
   requirements:
   - - ">="