Re: NEW: Tclthread
On 02/03/13 09:26, Stuart Cassoff wrote:
> On 02/03/13 09:02, Stuart Henderson wrote:
>> On 2013/02/03 06:58, Stuart Cassoff wrote:
>>> On 02/03/13 04:44, Landry Breuil wrote:
On Sat, Feb 02, 2013 at 12:38:40PM -0500, Stuart Cassoff wrote:
> Provides script-level access to Tcl's threading capabilities.
>>>
If i get it right it needs tcl sources to build ? Why not making it a
subpackage or bundle it with main tcl ?
>>>
>>> Starting with 8.6, several packages are bundled with the main Tcl
>>> distribution.
>>> I've split them into separate ports; not all are ready right now.
>>> The idea is to use the 8.6 tarball now and change a port to use the package
>>> distfile whenever a package is updated.
>>>
>>> No bundled packages need the Tcl sources to build.
>>> The Tcl people (not me) decided with 8.6 to start bundling packages.
>>> I had greater interest in getting 8.6 in than complicating things.
>>> Some people might like to take all this and make subpackages but I'd
>>> prefer to make separate ports and finally, put some notes into the
>>> README mentioning the bundled packages and which ports would need
>>> to be installed to have a 'full' 8.6+packages installation.
>>>
A better option would be to depend on tcl/8.6:patch so that you don't
need to update tcl version in two places when updating it, and you dont
need the extra DISTFILES handling. See for example how mplayer
build_depends on ffmpeg:patch.
>>>
>>> I'll have a look, thanks.
>>>
>>>
>>> Stu
>>> (not yet fully caffeinated)
>>>
>>
>> Especially as there will be more ports than just this one, it makes
>> sense to sort out the handling of this a bit..
>>
>> DISTNAME = thread2.7.0
>> PKGNAME = tclthread-2.7.0
>> DISTFILES = tcl8.6.0-src.tar.gz
>> WRKDIST = ${WRKDIR}/tcl8.6.0/pkgs/${DISTNAME}
>>
>> so... I think DISTNAME should get used for its normal purpose i.e.
>> the name of the distfile (DISTFILES is normally just used if you have
>> additional files). If not, then at the very least DISTFILES should
>> move up with DISTNAME/PKGNAME as otherwise it's more difficult than
>> it should be to see where the files are coming from; might be important
>> if someone who doesn't know the Tcl ports particularly well if they
>> have to update in a hurry e.g. for a security fix.
>>
>> I presume there will be a lot of commonality between this and the
>> ports for other modules, so it would make sense to arrange them in a
>> subdirectory so Makefile.inc could be used, or use a module.
>>
>> I would prefer a subdirectory (maybe lang/tcl86-extensions or
>> something..?) to help keep them together rather than stuffing more
>> things in the hugely busy devel/ directory.
>>
>> Hardcoding 8.6.0 in several places seems like a bad idea, I think
>> this should come from a module or Makefile.inc somewhere.
>>
>>
>>
>
> The 8.6 'core' and the bundled packages are all available as separate
> tarballs.
> I'd like to go that route and forget about the bundled stuff altogether.
> The main push behind the bundling was to get TDBC released and 'out there'.
> I doubt we'll see (m)any more packages bundled in subsequent releases.
> I don't know what to do about directory overcrowding, not really my bailiwick.
>
Here's version of the port that uses its own distfile instead of the
tcl-bundled one.
Stu
tclthread-2.7.0-port.tar.gz
Description: application/gzip
Re: NEW: Tclthread
On 02/03/13 09:02, Stuart Henderson wrote:
> On 2013/02/03 06:58, Stuart Cassoff wrote:
>> On 02/03/13 04:44, Landry Breuil wrote:
>>> On Sat, Feb 02, 2013 at 12:38:40PM -0500, Stuart Cassoff wrote:
Provides script-level access to Tcl's threading capabilities.
>>>
>>
>>> If i get it right it needs tcl sources to build ? Why not making it a
>>> subpackage or bundle it with main tcl ?
>>
>> Starting with 8.6, several packages are bundled with the main Tcl
>> distribution.
>> I've split them into separate ports; not all are ready right now.
>> The idea is to use the 8.6 tarball now and change a port to use the package
>> distfile whenever a package is updated.
>>
>> No bundled packages need the Tcl sources to build.
>> The Tcl people (not me) decided with 8.6 to start bundling packages.
>> I had greater interest in getting 8.6 in than complicating things.
>> Some people might like to take all this and make subpackages but I'd
>> prefer to make separate ports and finally, put some notes into the
>> README mentioning the bundled packages and which ports would need
>> to be installed to have a 'full' 8.6+packages installation.
>>
>>> A better option would be to depend on tcl/8.6:patch so that you don't
>>> need to update tcl version in two places when updating it, and you dont
>>> need the extra DISTFILES handling. See for example how mplayer
>>> build_depends on ffmpeg:patch.
>>
>> I'll have a look, thanks.
>>
>>
>> Stu
>> (not yet fully caffeinated)
>>
>
> Especially as there will be more ports than just this one, it makes
> sense to sort out the handling of this a bit..
>
> DISTNAME = thread2.7.0
> PKGNAME = tclthread-2.7.0
> DISTFILES = tcl8.6.0-src.tar.gz
> WRKDIST = ${WRKDIR}/tcl8.6.0/pkgs/${DISTNAME}
>
> so... I think DISTNAME should get used for its normal purpose i.e.
> the name of the distfile (DISTFILES is normally just used if you have
> additional files). If not, then at the very least DISTFILES should
> move up with DISTNAME/PKGNAME as otherwise it's more difficult than
> it should be to see where the files are coming from; might be important
> if someone who doesn't know the Tcl ports particularly well if they
> have to update in a hurry e.g. for a security fix.
>
> I presume there will be a lot of commonality between this and the
> ports for other modules, so it would make sense to arrange them in a
> subdirectory so Makefile.inc could be used, or use a module.
>
> I would prefer a subdirectory (maybe lang/tcl86-extensions or
> something..?) to help keep them together rather than stuffing more
> things in the hugely busy devel/ directory.
>
> Hardcoding 8.6.0 in several places seems like a bad idea, I think
> this should come from a module or Makefile.inc somewhere.
>
>
>
The 8.6 'core' and the bundled packages are all available as separate tarballs.
I'd like to go that route and forget about the bundled stuff altogether.
The main push behind the bundling was to get TDBC released and 'out there'.
I doubt we'll see (m)any more packages bundled in subsequent releases.
I don't know what to do about directory overcrowding, not really my bailiwick.
Stu
Re: NEW: Tclthread
On 2013/02/03 06:58, Stuart Cassoff wrote:
> On 02/03/13 04:44, Landry Breuil wrote:
> > On Sat, Feb 02, 2013 at 12:38:40PM -0500, Stuart Cassoff wrote:
> >> Provides script-level access to Tcl's threading capabilities.
> >
>
> > If i get it right it needs tcl sources to build ? Why not making it a
> > subpackage or bundle it with main tcl ?
>
> Starting with 8.6, several packages are bundled with the main Tcl
> distribution.
> I've split them into separate ports; not all are ready right now.
> The idea is to use the 8.6 tarball now and change a port to use the package
> distfile whenever a package is updated.
>
> No bundled packages need the Tcl sources to build.
> The Tcl people (not me) decided with 8.6 to start bundling packages.
> I had greater interest in getting 8.6 in than complicating things.
> Some people might like to take all this and make subpackages but I'd
> prefer to make separate ports and finally, put some notes into the
> README mentioning the bundled packages and which ports would need
> to be installed to have a 'full' 8.6+packages installation.
>
> > A better option would be to depend on tcl/8.6:patch so that you don't
> > need to update tcl version in two places when updating it, and you dont
> > need the extra DISTFILES handling. See for example how mplayer
> > build_depends on ffmpeg:patch.
>
> I'll have a look, thanks.
>
>
> Stu
> (not yet fully caffeinated)
>
Especially as there will be more ports than just this one, it makes
sense to sort out the handling of this a bit..
DISTNAME = thread2.7.0
PKGNAME = tclthread-2.7.0
DISTFILES = tcl8.6.0-src.tar.gz
WRKDIST = ${WRKDIR}/tcl8.6.0/pkgs/${DISTNAME}
so... I think DISTNAME should get used for its normal purpose i.e.
the name of the distfile (DISTFILES is normally just used if you have
additional files). If not, then at the very least DISTFILES should
move up with DISTNAME/PKGNAME as otherwise it's more difficult than
it should be to see where the files are coming from; might be important
if someone who doesn't know the Tcl ports particularly well if they
have to update in a hurry e.g. for a security fix.
I presume there will be a lot of commonality between this and the
ports for other modules, so it would make sense to arrange them in a
subdirectory so Makefile.inc could be used, or use a module.
I would prefer a subdirectory (maybe lang/tcl86-extensions or
something..?) to help keep them together rather than stuffing more
things in the hugely busy devel/ directory.
Hardcoding 8.6.0 in several places seems like a bad idea, I think
this should come from a module or Makefile.inc somewhere.
Re: NEW: Tclthread
On 02/03/13 04:44, Landry Breuil wrote: > On Sat, Feb 02, 2013 at 12:38:40PM -0500, Stuart Cassoff wrote: >> Provides script-level access to Tcl's threading capabilities. > > If i get it right it needs tcl sources to build ? Why not making it a > subpackage or bundle it with main tcl ? Starting with 8.6, several packages are bundled with the main Tcl distribution. I've split them into separate ports; not all are ready right now. The idea is to use the 8.6 tarball now and change a port to use the package distfile whenever a package is updated. No bundled packages need the Tcl sources to build. The Tcl people (not me) decided with 8.6 to start bundling packages. I had greater interest in getting 8.6 in than complicating things. Some people might like to take all this and make subpackages but I'd prefer to make separate ports and finally, put some notes into the README mentioning the bundled packages and which ports would need to be installed to have a 'full' 8.6+packages installation. > A better option would be to depend on tcl/8.6:patch so that you don't > need to update tcl version in two places when updating it, and you dont > need the extra DISTFILES handling. See for example how mplayer > build_depends on ffmpeg:patch. I'll have a look, thanks. Stu (not yet fully caffeinated)
Re: NEW: Tclthread
On Sat, Feb 02, 2013 at 12:38:40PM -0500, Stuart Cassoff wrote: > Provides script-level access to Tcl's threading capabilities. If i get it right it needs tcl sources to build ? Why not making it a subpackage or bundle it with main tcl ? A better option would be to depend on tcl/8.6:patch so that you don't need to update tcl version in two places when updating it, and you dont need the extra DISTFILES handling. See for example how mplayer build_depends on ffmpeg:patch. Landry
NEW: Tclthread
Provides script-level access to Tcl's threading capabilities. Stu tclthread-2.7.0-port.tar.gz Description: application/gzip
