BOOTSTRAP toolbox : 5-July-96


kroutines libraries scripts

conductor


ghostwriter


kcp



Short Description:
Request for kcp to copy *parts* of software objects
Work-Around :
Severity : 10a- enhancement request
Priority : 3 - Medium
Reported By : Danielle Argiro
Date : 24-Apr-96
HW : all
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
It would help in the software process if kcp could have the capability to copy parts of software objects. For example, you might do: % kcp -oname cantata -otb design -ntb guiviz -src -uis This would give you source code, uis, and whatever else was necessary, but not help pages or man pages Similarly, % kcp -oname cantata -otb design -ntb guiviz -help would only give you the help pages of cantata. This will help us when different people are working on different parts of a software object. Specifically, Mark working on code while Kelly is working on doc.
Notes :
Keywords :

kecho


kexec


kgendepend


kgenimake


kgenmake



Short Description:
script objects don't have a "Makefiles" target
Work-Around : Don't worry about it
Severity : 4b- Minor inconvenience
Priority : 3 - Medium
Reported By : Neil Bowers
Date : 30-Apr-96
HW : dec alpha (brandy)
OS : osf 3.0
Widget : athena
C : gcc
Fortran :
Perl :
X :
Win Mgr : ctwm
Display :
Original Rpt:
The Makefile generated for script objects doesn't have a "Makefiles" target.

For example, on brandy: % make Makefiles make: *** No rule to make target `Makefiles'. Stop.

Notes :
Keywords :

kgenmanual


kgenobj


kgenstruct


kgentb


kman


krename


krm


kset


phantomd


kclui


kcms



Short Description:
Inconsistent support for structures
Work-Around :
Severity : 10a - Enhancement request
Priority : 5 - None
Reported By : Jeremy Worley
Date : 18-Feb-96
HW : Sparc
OS : Solaris 2.4
Widget :
C : gcc
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
Support for .x files in the imake system seems to not be stable. The two things that I've noticed are:

- it would be cool if kgendepend would know to associate

#include "io_foo.h"

with foo.x and build the appropriate dependencies.

- associated with the second point, one should not have to type 'make struct' to generate the structure support code. I assume this is all known. Just getting it out on the table to be fixed before 2.1 goes out the door.
Notes :
Keywords :
TB::oname : BOOTSTRAP::kcms


Short Description:
code generator error handling of missing tags is not very nice.
Work-Around : Don't mess up the ghostwriter tags
Severity : 3a - Major inconvenience
Priority : 3 - Medium
Reported By : Jeremy Worley
Date : 18-Feb-96
HW : Sparc
OS : Solaris 2.4
Widget :
C : gcc
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
Well, 'bug' is perhaps too strong a term...but a minor change would make craftsman much more friendly in this one circumstance (imho, not a bad thing in a commercial quality product :^)

I did a little cut and paste in my favorite editor and accidentally closed a -main_after_lib_call with a -main_before_lib_call_end. When pushing the GenerateCode button, it pops up the following message, and patiently waits for me to accept this bad news:

Unable to find end key '^\s*/\* -main_after_lib_call_end \*/\s*$'; marking the ending of the text block for code to go after library call to go into the main program. This part of the generated code will be left empty.

I realized immediately what was wrong, but I could do nothing about it... when I hit 'Ok', it went on to generate the code, and deleted everything in the main_after_lib_call section, which I had to reproduce by hand.

If the message was changed to read:

Unable to find end key '^\s*/\* -main_after_lib_call_end \*/\s*$'; marking the ending of the text block for code to go after library call to go into the main program.

If you choose to continue, this part of the generated code will be left empty.

And then I am given the opportunity to bail out ('Continue' and 'Abort' are the two options), then I'd be much happier.
Notes :
Keywords :
TB::oname : BOOTSTRAP::kcms


Short Description:
copy object not updating -tb foo references to toolbox
Work-Around :
Severity : 2a- Incorrect behavior
Priority : 4 - Low
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
If you have a command line which includes:

-tb foobar ...

the toolbox reference will not be updated when copying the object to another toolbox.
Notes :
Keywords :
TB::oname : BOOTSTRAP::kcms


Short Description:
renaming a pane object with executable doesn't result in all renames
Work-Around : change executables references by hand
Severity : 2a- Incorrect behavior
Priority : 3 - Medium
Reported By : George Ruban
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
Anyway, when you change the name of the software object in craftsman, the name of the executable is only changed some places, not others. Specifically, the name of the executable to be generated is changed, while the name of the executable to be executed from the pane isn't. It may be this only occurs when the executable name differs from the object name.
Notes :
Keywords :
TB::oname : BOOTSTRAP::kcms


Short Description:
problem copying/renaming an encapsulated workspace object
Work-Around : none
Severity : 2a- Incorrect behavior
Priority : 3 - Medium
Reported By : Dave Modl
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
I am trying to copy and rename an encapsulated workspace from one toolbox to another. The copy works fine, but I get the following message from KCMS library routine when performing the rename operation on this program object:

_kcms_fobj_set_basename:

676 if (file_object->ftype == KCMS_FOBJ_TYPE_DBM) 677 { 678 kerror(KCMS, routine, 679 "You are not allowed to rename the object database files!"); 680 return FALSE; 681 }

When trying to rename the .wksp file. This file should not be a DBM type, so I think there is some bug in the classification of the wksp file type.
Notes :
Keywords :
TB::oname : BOOTSTRAP::kcms

kcodegen



Short Description:
inconsistency between command-line usage and man(1) page
Work-Around : To get the labels and thier associated values onto the man page forces the programmer to put a full description of thom in with the Description field. While this does get the info into the man page, it also causes that information to appear twice on the command line -U information - once for the stuff that kcodegen writes, and once for the stuff explicitly added.
Severity : 4b- Minor inconvenience
Priority : 3 - Medium
Reported By : Scott Wilson swilson@khoral.com
Date : 29-Feb-96
HW : zen
OS : Solaris
Widget :
C :
Fortran :
Perl :
X :
Win Mgr : twm
Display :
Original Rpt:
There is an inconvenient behavior in the way kcodegen writes up a kroutine.1 man page. This report documents the problem using the cycle selection type, but others such as list, etc will probably also show the same symptoms.

In the UIS file for a cycle, the cycle values/labels are specified. The labels and thier associated values are listed when you do a % kroutine -U but if you look at the man page, they are absent.

For an example of this, look at irotate for the padding behavior cycle (-padding).
Notes :
Keywords :
TB::oname : BOOTSTRAP::kcodegen


Short Description:
no warning if # subform buttons don't match # subforms
Work-Around :
Severity : 3a- Major inconvenience
Priority : 2 - High
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
If you comment out the -d (subform button) for a subform, leaving the subform UIS intact, conductor runs without any complaints, but doesn't generate the form structure(s) for the subform. Conductor should give a warning that an orphan subform was found.
Notes :
Originally recorded as a conductor bug
Keywords :
TB::oname : BOOTSTRAP::kcodegen


Short Description:
generated callbacks not added to comment at head of file
Work-Around :
Severity : 10a- Enhancement request
Priority : 4 - Low
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
When you add new "live" selections or action buttons, the "do" routines are generated in the appropriate file, but the header is not updated to include the names of the new routines.
Notes :
This is because, once created, the "do_*.c" files are not touched - only appended to; this is to make sure that no modifications made by the developer are over-written. It would take some planning to think of a scheme whereby conductor could recognise the header and re-generate it, but not touch anything else that currently exists in the file.

Originally recorded as a conductor bug
Keywords :
TB::oname : BOOTSTRAP::kcodegen


Short Description:
unnecessary code generated for multiple panes on single subform
Work-Around : Just don't worry about it; it doesn't interfere with the operation of the xvroutine.
Severity : 10a- enhancement request
Priority : 4 - Low
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
xvroutine with multiple panes on single subforms, no selections: conductor generates un-necessary code

xvroutine with multiple panes on single subforms, no "live" selections: conductor generates un-necessary code it would be nice if code generator was smart enough to only generate necessary code
Notes :
Originally recorded as a conductor bug
Keywords :
TB::oname : BOOTSTRAP::kcodegen


Short Description:
overwrite prompting not usable when big differences between help and man pages
Work-Around : Always modify man page. Default action is to update using manpage information.
Severity : 4d- Error message, warning, or prompting is unclear
Priority : 4 - Low
Reported By : Ashish Malhotra
Date : 26-Nov-93
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
For the case when the man and help pages of an object are different, Ghostwriter prints out both the man and help pages and prompts for a selection. If the man & help pages are long and scroll out of the window, it is difficult to make out whether a selection number refers to the man or the help page. It'd be nice to print out the pages followed by a message saying what each selection refers to. Thanx, Ashish
Notes :
Originally recorded as a ghostwriter bug
Keywords :
TB::oname : BOOTSTRAP::kcodegen


Short Description:
overlong short descriptions cause problems in .pane file
Work-Around :
Severity : 4b- Minor inconvenience
Priority : 4 - Low
Reported By : Mark Young
Date : 6-May-96
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
I'm having a problem with descriptions in my pane file that are too long when printed out with a "dprog -U" command or a missing/illegal argument. For example:

[-d] data processing direction (0 = down vectors, 1 = across bands) (boolean) [true]

The solution is probably as simple as writing each line out to a string first and doing a strlen() on it and formatting it by inserting carraige reurns at the nearest whitespace before column 80.

Notes :
Keywords :
TB::oname : BOOTSTRAP::kcodegen

kexpr


kforms



Short Description:
Pane objects can't have arguments with default values that differ from the kroutine that they get their functionality from
Work-Around : Use same defaults as kroutine, or turn the pane object into a script object or a kroutine that forks off the other kroutine with the desired arguments.
Severity : 3a- Major inconvenience
Priority : 3 - Medium
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
Pane objects can't have arguments with default values that differ from the kroutine that they get their functionality from. The differing default value is simply ignored, and the default of the kroutine is what gets used.
Notes :
Fixing this is a *very* difficult problem; weigh benefit of fix against instability of system that will be introduced as a result of trying to fix the bug.
Keywords : CLUI, clui
TB::oname : BOOTSTRAP::kforms


Short Description:
UIS line parser doesn't give error message when there are too many fields in a UIS line
Work-Around :
Severity : 4d- error message unclear (in this case, lacking)
Priority : 5 - None
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
UIS line parser doesn't give error message when there are too many fields in a UIS line; the additional fields are simply ignored. It would be nicer for the developer if an error message was issued. This is not so much of an issue now that guise is used so heavily.
Notes :
Keywords : CLUI, clui
TB::oname : BOOTSTRAP::kforms


Short Description:
It would be nice if the [-R] UIS line provided support for execution of programs with varying (non-Khoros) syntax
Work-Around :
Severity : 10a- enhancement request
Priority : 5 - None
Reported By : Danielle Argiro
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
It would be nice if the [-R] UIS line provided support for execution of programs with varying (non-Khoros) syntax. This would make K2 even better for use as a software integration environment
Notes :
Keywords : CLUI, clui
TB::oname : BOOTSTRAP::kforms

klibdb


klibm



Short Description:
klibm.h has incorrect prototyping for C++ compilers on srandom for linux (fix included in report)
Work-Around : Use fix below
Severity : 10a - Enhancement request
Priority : 4 - Low
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
The definition of srandom in klibm.h conflicts with the definition in /usr/include/stdlib.h gcc in C++ mode flags this as an error.

Reproduce By: ------------- Compile the following C++ file:

#include extern "C" { #include };

Fix: ---- *** /usr/local/khoros/K2/bootstrap/include/klibm/klibm.h.org Sat Apr 8 23:52:28 1995 --- klibm.h Mon Feb 5 10:41:35 1996 *************** *** 1800,1806 **** #else # define ksrandom srandom # if KOPSYS_LOCAL != KOPSYS_OSF ! void srandom PROTO((int)); # endif #endif

--- 1800,1810 ---- #else # define ksrandom srandom # if KOPSYS_LOCAL != KOPSYS_OSF ! # if KOPSYS_LOCAL != KOPSYS_LINUX ! void srandom PROTO((int)); ! # else ! void srandom PROTO((unsigned int)); ! # endif # endif #endif
Notes :
The fix above is fine for short term, but this problem needs to be addressed in general for C++ and that will take considerably more time than the fix above.
Keywords :
TB::oname : BOOTSTRAP::klibm

ktestutils


kutils



Short Description:
Need a function to translate sh wild card syntax to regular expression syntax.
Work-Around :
Severity : 10a - Enhancement request
Priority : 1 - Mandatory
Reported By : Steven Kubica
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
guiviz group would like a sh to regex wild card translation routine so that wild cards can be used by the browser.
Notes :
Keywords :
TB::oname : BOOTSTRAP::kutils


Short Description:
Need a kftruncate function
Work-Around :
Severity : 10a - Enhancement request
Priority : 1 - Mandatory
Reported By : Steven Kubica
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
A ktrunc or ktruncate function which truncated an open fid is needed to deal with read/write data objects or programs which use the same file for -i and -o in the new data services.
Notes :
Keywords :
TB::oname : BOOTSTRAP::kutils


Short Description:
Exit status for remote processes are not correctly returned after execution
Work-Around :
Severity : 2a- Incorrect behavior
Priority : 4 - Low
Reported By : Bob Stevens
Date : 31-Mar-93
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
kexecvp() seems to return (successfully) regardless of the exit status of the process that it was supposed to execute, when that process is remote (i.e., on a different machine). Example (using kexec):

erendis 71% kexec -c spam sh: spam: not found erendis 72% echo $status 1 erendis 73% kexec -c spam@surak erendis 74% echo $status 0

erendis 75% kexec -c date@surak Wed Mar 31 14:32:50 MST 1993 erendis 76% echo $status 0

NOTE: erendis is the local machine, surak is the remote machine NOTE: kexecvp() behaves the same way as kexec().

line 71: kexec() tries to execute a non-existant program A shell error message appears. line 72: the "status" shell variable is set (indicating a non-successful exit). line 73: kexec() tries to run the same process on a remote machine (surak) line 74: the exit status is (wrongly) zero (indicating successful exit). line 75: when kexec() tries to run a real program on surak, it works, and line 76: the exit status is correct (zero).

Hi, Yes this is a bug. Unfortunately the status is not passed back from the remote phantomd, which performs the actual exec. So it simply assumes all is well. A command channel should be between the phantomd's so that information of this sort can be passed back and forth. This problem will definitely be fixed for K2. Thanks for the bug report...

Bob Stevens, MEE-13, Los Alamos National Laboratory, stevens@lanl.gov, 505-667-2623
Notes :
Keywords :
TB::oname : BOOTSTRAP::kutils


Short Description:
Our kscanf does not work on the Cray when doing a %p.
Work-Around : don't use %p
Severity : 2a- Incorrect behavior
Priority : 4 - Low
Reported By : John Salas
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
Our kscanf does not work on the Cray when doing a %p.
Notes :
Keywords :
TB::oname : BOOTSTRAP::kutils


Short Description:
LARGE static buffer always created for regex routines, whether they are used or not - need to be smarter about this
Work-Around :
Severity : 4b- Minor inconvenience
Priority : 2 - High
Reported By : Wolfram Gloger (wmglo@dent.med.uni-muenchen.de)
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
currently the regex routines has a large static buffer that is always created whether the regex routines are called or not. This needs to be changed so that it is smaller and that it is malloc'ed at run time on the first call to kre_comp.
Notes :
Keywords :
TB::oname : BOOTSTRAP::kutils


Short Description:
avoiding dependence on *any* environment variables
Work-Around : Require that users source the .khoros_env within their login for remote command execution (ie. no prompt defined).
Severity : 3a- Major inconvenience
Priority : 2 - High
Reported By : Mark Young
Date : 02-Apr-96
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
Need to remove the dependence on the KHOROS_TOOLBOX variable. This makes 2.0 distributed computing less robust and susceptable to the same 1.0 setup failures.

Most of the infrastructure has been put in place to do this. It's just a question of finializing the mods so that if the KHOROS_TOOLBOX variable is not set then we search the user's home directory for their .Toolboxes file. Then kconfigure should be changed to use an include syntax within this file to reference system include toolboxes.

The problem is that other programs such as kgenmake, kutils.pl, etc. will have to be modified to understand this syntax. Last time we did this it took a day of fixing to get things back online. So it's not as simple as doing a kcp of kutils.

Also, this also means that toolbox addition will have to be added not to just append the new toolbox to the list. Cantata and aliases depend on the order of toolboxes be user toolboxes followed by system toolboxes.
Notes :
One thing that we have been trying to do is delete any kind of environment dependence for running Khoros related programs. This was mainly done for distributed computing. The biggest single failure in the Khoros 1.0 distributed computing mechanism was the fact that the user had to setup their environment so that the Khoros binaries and environment variables were properly set in their .cshrc. The problem seems to occur that most people don't want to source have an environment that it is difficult to enforce.

So for 2.1 if don't make this change we may take a hit in distributed computing being robust enough to be useable.
Keywords : KHOROS_TOOLBOX distributed computing
TB::oname : bootstrap::kutils


Short Description:
Directories created without warning.
Work-Around :
Severity : 3a- Major inconvenience
Priority : 2 - High
Reported By : Mark Young
Date : 02-Apr-96
HW : mohawk
OS : linux
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
If you open a file which has a leading path that doesn't exist then the directories are created. This was done as an ease of convience, but what happens if you typo in the directory while saving a workspace then this directory will be created.

It would be better to prompt the user that the directory doesn't exist and ask if they want it created. However, this will be a problem for the existing infrastructure that relies on this feature.
Notes :
It seems important to fix this for the final release as we can really piss off a lot of users. I have the fix in my work toolbox, but and have added a KOPEN_CREATEDIR flag that can be specified in order to avoid the prompting.
Keywords : bogus directories
TB::oname : bootstrap::kutils


Short Description:
temporary files not being cleaned up in /var/tmp

Work-Around : use rm to remove them after running testsuites or cantata.
Severity : 3a- Major inconvenience
Priority : 1 - Mandatory
Reported By : Mark Young
Date : 03-Apr-96
HW : SparcServer 1000
OS : Solaris 2.4
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
Cantata, dataservices operators, and data testsuites are still leaving temporary files behind. Not sure why, but this really needs to be fixed. Eventually cantata starts failing because there is no more temporary space.
Notes :
Need to hack kutils after bronze to warn if you ever exit a program without unlinking a temporary file. At least this will allow us to track down which programs under which conditions are leaving these temporary files around.
Keywords : temporary files
TB::oname : bootstrap::kutils

kbugreport


kbuild



Short Description:
kbuild really won't work if it can't find design/lib
Work-Around : mkdir design; mkdir lib in Khoros toplevel
Severity : 4b- minor inconvenience
Priority : 4 - Low
Reported By : Steve Kubica
Date : 19-Mar-96
HW : intel486
OS : Linux 1.0
Widget : Athena
C : gcc
Fortran :
Perl :
X : XFree86
Win Mgr : ctwm
Display :
Original Rpt:


Can't do anything unless you have the base 3 toolboxes.

I took home just bootstrap and dataserv and tried to build just bootstrap. It complained about not being able to find design/lib to check dependencies, and failed to compile bootstrap.
Notes :
Keywords :
TB::oname : BOOTSTRAP::kbuild


Short Description:
kbuild wouldn't let me edit my config file
Work-Around : go edit them outside of kbuild
Severity : 4b- minor inconvenience
Priority : 1 - Mandatory
Reported By : Steve Kubica
Date : 19-Mar-96
HW : intel486
OS : Linux 1.0
Widget : Athena
C : gcc
Fortran :
Perl :
X : XFree86
Win Mgr : ctwm
Display :
Original Rpt:


When prompted to see if I wanted to edit my config files, I typed 'y' and it ignored me.

Notes :
Keywords :
TB::oname : BOOTSTRAP::kbuild


Short Description:
kbuild assumes you are running a csh-like shell
Work-Around :
Severity : 3a - Major inconvenience
Priority : 1 - Mandatory
Reported By : Robert Forsman
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
The kbuild program assumes you are running a shell derived from csh. I run bash which is derived from sh.
Notes :
This is actually a problem with kconfigure, but it also may be fixed with the last rewrite. (SJ)
Keywords :
TB::oname : BOOTSTRAP::kbuild


Short Description:
kbuild assumes the compiler will be in your PATH
Work-Around :
Severity : 2a- Incorrect behavior
Priority : 1 - Mandatory
Reported By : Robert Forsman
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
The kbuild program assumes the C compiler will be in your PATH. This is wrong. I specified a path beginning with / and it choked.
Notes :
Keywords :
TB::oname : BOOTSTRAP::kbuild


Short Description:
Installit should state version being installed
Work-Around : read the release notes? :-)
Severity : 4d- Error message, warning, or prompting, is unclear
Priority :
Reported By : Neil Bowers
Date : 11-Apr-96
HW : Pentium 100 (i586)
OS : FreeBSD 2.1
Widget :
C :
Fortran :
Perl :
X : X11R6
Win Mgr : ctwm 3.3
Display :
Original Rpt:
Installit just says "Khoros 2 Installation". It needs to be clear exactly what version is being installed.
Notes :
Keywords :
TB::oname : BOOTSTRAP::kbuild


Short Description:
It'd be nice to say what in environment is checked
Work-Around : read the release notes? :-)
Severity : 5a- Aesthetics (typos, minor UI inconsistencies, etc)
Priority :
Reported By : Neil Bowers
Date : 11-Apr-96
HW : Pentium 100 (i586)
OS : FreeBSD 2.1
Widget :
C :
Fortran :
Perl :
X : X11R6
Win Mgr : ctwm 3.3
Display :
Original Rpt:
Near the start you get a message:

Checking your environment to make sure it is set up correctly....

It'd be nice if you got something like:

Checking your environment ... blah blah blah blah Looks good!

Notes :
Keywords :
TB::oname : BOOTSTRAP::kbuild


Short Description:
give pointer to definition of `supported' etc
Work-Around : read the installation guide
Severity : 5a- Aesthetics (typos, minor UI inconsistencies, etc)
Priority :
Reported By : Neil Bowers
Date : 11-Apr-96
HW : Pentium 100 (i586)
OS : FreeBSD 2.1
Widget :
C :
Fortran :
Perl :
X : X11R6
Win Mgr : ctwm 3.3
Display :
Original Rpt:
When giving the list of platforms there is no mention of what supported, development, and ported mean.

Maybe just a comment in parentheses like (see Installation Guide for definitions of `supported', 'development', etc)
Notes :
Keywords :
TB::oname : BOOTSTRAP::kbuild


Short Description:
no section heading for "toolbox selection" step
Work-Around :
Severity : 5a- Aesthetics (typos, minor UI inconsistencies, etc)
Priority :
Reported By : Neil Bowers
Date : 11-Apr-96
HW : Pentium 100 (i586)
OS : FreeBSD 2.1
Widget :
C :
Fortran :
Perl :
X : X11R6
Win Mgr : ctwm 3.3
Display :
Original Rpt:
When you're asked to select the toolboxes to install, there is no heading, as there is in all previous steps (or so it seemed).

Just something like:

Toolbox Selection

Notes :
Keywords :
TB::oname : BOOTSTRAP::kbuild


Short Description:
give useful default when selecting toolboxes
Work-Around : type the numbers yourself
Severity : 4b- Minor inconvenience
Priority : 2 - High
Reported By : Neil Bowers
Date : 11-Apr-96
HW : Pentium 100 (i586)
OS : FreeBSD 2.1
Widget :
C :
Fortran :
Perl :
X : X11R6
Win Mgr : ctwm 3.3
Display :
Original Rpt:
When prompting for which toolboxes to install, the default is "None".

It would be helpful if the default was determined by looking to see which toolboxes are in the top directory, and using those as the default.

For example, I am just installing BOOTSTRAP, DATASERV, DESIGN, and SUPPORT, so would get:

blah blah toolbox(es) [1 2 3 10]:

Notes :
Keywords :
TB::oname : BOOTSTRAP::kbuild


Short Description:
HasGcc stuff
Work-Around :
Severity : 4b- Minor inconvenience
Priority : 2 - High
Reported By : Neil Bowers
Date : 11-Apr-96
HW : Pentium 100 (i586)
OS : FreeBSD 2.1
Widget :
C :
Fortran :
Perl :
X : X11R6
Win Mgr : ctwm 3.3
Display :
Original Rpt:
When selecting the C compiler, it mentioned that you should set HasGcc and HasGcc2 to YES if your compiler was cc, but is really gcc.

At that point you could let the user know that there'll be a chance to edit the file later on.

When that time comes, remind them to check HasGcc.
Notes :
Keywords :
TB::oname : BOOTSTRAP::kbuild


Short Description:
auto detection of /usr/X11R6 would be helpful
Work-Around :
Severity : 4b- Minor inconvenience
Priority : 2 - High
Reported By : Neil Bowers
Date : 11-Apr-96
HW : Pentium 100 (i586)
OS : FreeBSD 2.1
Widget :
C :
Fortran :
Perl :
X : X11R6
Win Mgr : ctwm 3.3
Display :
Original Rpt:
kbuild could check for the existence of /usr/X11R6 on PC unixes and set X11LibDir and X11IncludeDir
Notes :
Keywords :
TB::oname : BOOTSTRAP::kbuild


Short Description:
cc command not properly updated.
Work-Around :
Severity : 2a- Incorrect behavior
Priority : 2 - High
Reported By : Wes Bethel wes@mh1.lbl.gov
Date : 29-Apr-96
HW : sparc lx
OS : solaris 2.4, older sparcworks, not sure which version
Widget : motif
C : acc
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
Reproduce By:

i have an older version of sparcworks on one of my machines. it's soooo old, i have to specify "acc" rather than cc. in the appropriate config file, the CcCmd variable remains set at cc.

Notes :
Keywords :
TB::oname : kbuild
Severity : 10a- Enhancement request
Priority : 2 - High
Reported By : Roberto A. Lotufo lotufo@dca.fee.unicamp.br
Date : 22-Apr-96
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
we do not use lex/yacc here as there were updated a long timeago for bison/flex

It would be good if you could support those.

below are the result of my compulation using bison/flex and the changes I did in the Makefile

Notes :
Keywords :
TB::oname :

kconfigure



Short Description:
kconfigure says it found binaries, but it didn't!
Work-Around :
Severity : 4d- Error message, warning, or prompting, is unclear
Priority : 2 - High
Reported By : Neil Bowers
Date : 11-Apr-96
HW : Pentium 100 (i586)
OS : FreeBSD 2.1
Widget :
C :
Fortran :
Perl :
X : X11R6
Win Mgr : ctwm 3.3
Display :
Original Rpt:
When kconfigure is run for you after running kbuild, it says:

bootstrap binaries located in [...] dataserv binaries located in [...] design binaries located in [...]

ok so far . . .

datamanip binaries located in [...] [similar for all standard toolboxes

I know this is checking where they would be installed, but I haven't even installed DATAMANIP et al, so this is a little misleading perhaps.

Notes :
Keywords :
TB::oname : BOOTSTRAP::kconfigure

kgenglossary


kgenindex


klicense


kversion