| Store | Cart

Re: [TCLCORE] TIP #453: Tcl Based Automation for tcl/pkgs

From: Christian Gollwitzer <auri...@gmx.de>
Mon, 19 Sep 2016 23:04:26 +0200
Am 18.09.16 um 19:46 schrieb tcl-...@lists.sourceforge.net:
> Date: Wed, 14 Sep 2016 15:27:44 +0200> From: Lars Hellstr?m <Lars...@residenset.net>> Subject: Re: [TCLCORE] TIP #453: Tcl Based Automation for tcl/pkgs> To: tcl-...@lists.sourceforge.net> Message-ID: <57D9...@residenset.net>> Content-Type: text/plain; charset=windows-1252; format=flowed>> Sean Woods skrev 2016-09-14 12.41:>>>>   TIP #453: TCL BASED AUTOMATION FOR TCL/PKGS> [snip]>>   ABSTRACT>> ==========>>>>   This TIP proposes replacing the *make package* process currently>>   employed by the core with a Tcl-based build automation tool.

I generally agree with the idea of having a standardized build system. 
There are multiple of these systems in existence now, and I suggest to 
take a look at these different implementations to pick the cherries from 
all.

For instance, Paul Obermeier's recent BAWT has the capability to drive 
(different versions of) the microsoft compiler in addition to gcc, which 
is useful on Windows.

kbs.tcl - the original kit builder from JCW, enhanced and maintained by 
Rene Zaumseil - has an appealing syntax of it's DSL to declare packages.

Both can build standard tcl interpreters and extensions as well as tclkits.

>>   Each *pkgs/* file system for both Tcl and Tk will also contain a file>>   *packages.tcl*. This file will be human and machine readable. It>>   contains a description of every core distributed package, where the>>   sources can be found, as well as which fossil tags can be utilized as>>   either development or release with this particular version of the core.

Sounds reasonable. It would be good if there was a standard way to 
declare new extensions to that system, for instance by passing an URL to 
the package definition script, such as

	make.tcl http://my.domain.org/project/project.pkg


>>   *packages.tcl* contains a series of commands that are designed to be>>   run from a practcl object:>> Is it really wise to tie declaration syntax that tightly to one particular> implementation? Some abstraction seems advisable.>>>   A simple example would by the tclconfig templates from TEA:>>>>     my add_project tclconfig {>> "my add_project"?!? This might well be what it ends up doing, but as a> public interface it's not looking sane. At the very least do indirection to> [my add_project] via an alias or similar. Think declaratively, because that> is the mode of thought authors will have when writing these files!

I agree with Lars. For comparison, this is how a simple TEA-compliant 
package is declared when using kbs.tcl:

Package photoresize0.1 {
   Require {Use tcl8.6 tk8.6}
   Source {Wget https://github.com/auriocus/PhotoResize/archive/master.zip}
   Configure {
     Config [Get srcdir-sys]
   }
   Make {Run make}
   Install {Run make install}
   Clean {Run make clean}
   Test {Run make test}
}

if this is placed in a file photo.pkg, then
	./kbs.tcl -pkgfile=photo.pkg -r install photoresize0.1
will download and build the package, ensuring that Tcl & Tk 8.6 are present.

I am not advocating the implementation of kbs, that is convoluted and a 
bit messy. But the interface, for me as a package author, is very clear.

>>   In a more complex example, we are building a Tk extension that needs a>>   modified vfs-install method:>>>>     my add_project tkimg {>>        profile {>>           release: c2fcb74d748b268483ed055492a956d89dc0bbd7>>           devel: trunk>>        }>>      [...]

why does tkimg need this special treatment? For comparison, here is the 
package definition for tkimg from kbs:

Package img1.4.3 {
   Source {Svn https://svn.code.sf.net/p/tkimg/code/trunk -r 374}
   Configure {
     Config [Get srcdir-sys]
   }
   Make {Run make collate}
   Install {
     Run make install-libraries
     Libdir Img1.4.3
   }
   Clean {Run make clean}
}

A complex example,  which patches the Tcl core, builds many extensions 
and links it into a runnable tclkit (VecTcLab) is found here:

https://github.com/auriocus/VecTcl/blob/master/build/vectcl.pkg

>>   The general form for the *add_project* method is:>>>>         /name/ /key/value-configuration-dict/

I think this is not so much different from kbs, where the make script is 
a key-value list, too,  with keys Source, Configure, Make,... and the 
values are scripts executed in a special context.

	Christian


------------------------------------------------------------------------------
_______________________________________________
Tcl-Core mailing list
Tcl-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tcl-core

Recent Messages in this Thread
Christian Gollwitzer Sep 19, 2016 09:04 pm
Donal K. Fellows Sep 20, 2016 08:47 am
Messages in this thread