KBS question

[Busirane]

I've been using the prebuilt KBS kits from https://sourceforge.net/projects/kbskit/files/kbs/0.4.9/, but now I need to build my own in order to selectively update some package versions. I have successfully built -dyn and -bi kits with sqlite3.25.3 instead of sqlite3.13.0. What I'd like to do now is either:

1. Build a -bi kit with dynamic Tk instead of static, or
2. Build a -dyn kit with additional packages.

I read up about KBS packages at https://wiki.tcl-lang.org/page/kbs+packages, but things seem to have changed since then. My sources tree contains no *.kbs or *kbskit* files, so I'm not sure how to define what I want. I did some quick searches in kbs.tcl, but nothing jumped out at me. Is it possible to do what I want?

[Christian Gollwitzer]

Am 19.03.19 um 22:41 schrieb Busirane:

> I've been using the prebuilt KBS kits from https://sourceforge.net/projects/kbskit/files/kbs/0.4.9/, but now I need to build my own in order to selectively update some package versions. I have successfully built -dyn and -bi kits with sqlite3.25.3 instead of sqlite3.13.0.

You can also have a look at https://github.com/auriocus/kbskit where I
have updated everything to Tcl/Tk 8.6.9 and the corresponding packages.

Christian

[Busirane]

On Wednesday, March 20, 2019 at 4:38:06 AM UTC-4, Christian Gollwitzer wrote:
> You can also have a look at https://github.com/auriocus/kbskit where I
> have updated everything to Tcl/Tk 8.6.9 and the corresponding packages.

Thank you, Christian, I'm sure that will come in handy in the future. But I'm still trying to figure out how to make a -bi kit dynamic, or add "batteries" to a -dyn kit.

Also trying to wrap my head around mingw/msys vs cygwin, which is better when, and why. Mingw is frustrating: the 32-bit installer mingw-get-setup.exe works, but doesn't let you install 64-bit stuff, and the 64-bit installer mingw-w64-install.exe fails with an error that it can't download repository.txt.

[Peter Dean]

Try msys2 installer. It's very easy. Can have both 32 and 64 bit
toolchains installed at the same time. And it uses the great pacman
package manager from arch linux.

https://www.msys2.org/

[Busirane]

On Tuesday, March 19, 2019 at 5:41:04 PM UTC-4, Busirane wrote:
> What I'd like to do now is either:
>
> 1. Build a -bi kit with dynamic Tk instead of static, or
> 2. Build a -dyn kit with additional packages.

I figured out how to #2, and also figured out how to build a Windows wish86 or kbsvq8.6-dyn that actually works without throwing the error "FindResource() failed for buttons bitmap resource, resources in tk_base.rc must be linked into Tk dll or static executable."

To get a -dyn kit with "batteries included", modify sources/kbskit0.4/Makefile.in and add $(MYKITBI) to the last line of the $(KBSVQ_DYN) target; this was line 289 for KBS 0.4.9. If you still want a normal -dyn kit you can also create a whole new target such as $(KBSVQ_DBI), but that requires a little more modification. A -dyn kit built from the modified target will contain all the -bi=".." packages.

Regarding the non-functioning wish86 and kbsvq8.6-dyn, I now know how to get working builds, but I'm not sure what the underlying problem is. The problem is somehow related to the order in which things are built, or possibly to the use of the -r flag. Starting from a clean slate, which for me means nothing but kbs.tcl and sources unpacked from kbs.tgz, I tried building two different ways:

1. Build things incrementally, without using the -r flag. I haven't absolutely verified this yet, but I think the same thing could be done with one command invocation like

tclsh kbs.tcl -vq -bi=".." install tcl8.6 tk8.6 .. vfs1.4 vqtcl4.1 kbskit8.6

where .. represents my "batteries included" packages for the -dyn kit.

2. Build everything at once with one command invocation like

tclsh kbs.tcl -r -vq -bi=".." install kbskit8.6

This is the approach typically found in KBS "getting started" or "how to build" tutorials, but it seems to produce a bad Tk, at least on Windows 10.

The difficulty is that the buildWindowsNT/tk8.6/Makefile generated by these two approaches has one (and only one) difference: The AC_FLAGS for #2 includes -DSTATIC_BUILD=1, where #1 doesn't. That flag causes the resulting wish86 to throw the above error when you do a simple "button .b". You can edit the Makefile to remove the offending flag, and rebuild, and the resulting wish86 works. I don't know enough about configure, or how kbs.tcl works, to know what the underlying problem is. But, I found a workaround (don't use the -r flag) so I'm a happy camper.

[Busirane]

On Wednesday, April 10, 2019 at 3:00:44 PM UTC-4, Busirane wrote:
> I haven't absolutely verified this yet, but I think the same thing could be done with one command invocation like
>
> tclsh kbs.tcl -vq -bi=".." install tcl8.6 tk8.6 .. vfs1.4 vqtcl4.1 kbskit8.6
>
> where .. represents my "batteries included" packages for the -dyn kit.

No, it can't, because that still results in the buildWindowsNT/tk8.6/Makefile defining AC_FLAGS with the undesired -DBUILD_STATIC=1. My fix is to modify the Require section of Package kbskit8.6 in kbs.tcl so that tk8.6 precedes tk8.6-static, like this:

Use tk8.6 tk8.6-static vfs1.4-static {*}[Get bi]

Now, starting from scratch, I can build a working kbsvq8.6-dyn with:

tclsh kbs.tcl -r -vq-dyn -bi=".." install kbskit8.6

which uses the -r switch with the kbskit8.6 target, as recommended by most online sources, it seems. The resulting kit has dynamic TK and selected "batteries included", which is what I want.

[rhobart]

I downloaded kbskit and everything compiled until the end. I got 1 error that prevented the kbskit8.6 from being installed.
All packages compiled except tkdnd2.9
Here is the generated error:
In file included from /Users/developer/scripts/tcl/kbskit-master/sources/tkdnd2.9/macosx/macdnd.m:23:
kbskit-master/sf86/include/tkMacOSXInt.h:62:13: error: ARC forbids Objective-C objects in struct
NSView *view;
I'm running MacOS Sierra 10.12.6

[rhobart]

I should of noted that I was referring to Christian Gollwitzer post and tried the fork at https://github.com/auriocus/kbskit
Perhaps I can just exclude the 1 package that caused the error (tkdnd2.9)

[Christian Gollwitzer]

Am 17.04.19 um 02:44 schrieb rhobart:

Thank you for the feedback. Yes, you can exclude the package by removing
the line with tkdnd2.9 in line 2001 of kbs.tcl. You may need to delete
everything in the sf86 directory and start afresh, because the script
gets often confused when there are left-over half-compiled packages.

Concerning the error, I have no clue what exactly causes this, it is
some problem with the garbage collection. It is mysterious because the
error comes from a Tk header file. I'm on High Sierra 10.13.6, where
this runs through. Maybe you can update your Xcode command line tools?

Christian

[rhobart]

Thanks Christian!
I removed line 2001 and all went well. Kit had "Batteries included" and was located in the sf.net directory (ex Darwin_kbsvq8.6-bi)and used the Tk aqua theme. For some odd reason the file in the Darwin directory (Darwin->bin/tclsh8.6) had the x11 Tk gui; strange. Still testing packages. I especially like the kbs.tgz file it produced.
As far as the error, my tool chain was up to date for the OS installed.
I also emptied the directory and started over but same error.
Nothing wrong with the script, just a compile error on 1 package.

I believe that perhaps the tkMacOSXInt.h
if modified like below line may have solved the compile problem:
__unsafe_unretained NSView *view;

struct TkWindowPrivate {
TkWindow *winPtr; /* Ptr to tk window or NULL if Pixmap */
NSView *view;
CGContextRef context;
int xOff; /* X offset from toplevel window */
int yOff; /* Y offset from toplevel window */
CGSize size;
HIShapeRef visRgn; /* Visible region of window */
HIShapeRef aboveVisRgn; /* Visible region of window & its children */
HIShapeRef drawRgn; /* Clipped drawing region */
int referenceCount; /* Don't delete toplevel until children are
* gone. */
struct TkWindowPrivate *toplevel;
/* Pointer to the toplevel datastruct. */
int flags; /* Various state see defines below. */
};
typedef struct TkWindowPrivate MacDrawable;

When I change the file in above with modification a new file one from the repository download replaces it.
I really don't need the package, but I just wanted to give some feedback.
Seems like Apple is always changing and depreciating api and compiler things.

[rhobart]

Follow up. After much research above is not the solution. My command line tool chain needs to be updated to LLVM 10. Can't upgrade Xcode without upgrading to macOS 10.14.3 . The clang version 10 addresses the above problem; in which I don't understand why macports compiles using clang version 9.
I went to macports.org and it compiled without errors and installed (tkdnd-2.8) even though the port said 2.9. In doing so macport updated tcl and tk to version 8.6.9
My use of tk is with +quartz so the tkdnd must also use +quartz
By default of the tkdnd port file defaults to +x11

Not sure if this will help others, but I thought I would share for those targeting the Mac.

[cl...@cflynt.com]

Hi,
I've succeeded at building Linux and Windows wishkits with the slightly reworked kitgen build system that Steve Huntley reported at the last Tcl-US.

I used Ubuntu Linux and the Linux ming tools. It took me several iteratations to get all the flags correct, and even then I ended up hardcoding some pieces rather than passing the new flag from the top down.

Perhaps, as a community, what we need is a virtual machine appliance that folks can download with all the parts and configuration options set so the builds will "just work".