Re: [REQADM-Users-L] REQADM moved to SourceForge

[Steve W. <st...@al...>]

In message <86f...@at...>, Tom Ivar Helbekkmo writes:
>It's taking me some time, actually.  Christmas preparations have
>started, and spare time is not copious.  :-)  I did manage to get the

Yeah, for me as well, so we'll see how kind the holidays are to making
more progress on the new REQADM database module. :)

>whole thing compiled and linked under NetBSD-current, with GCC 3.3,
>but not without a few tweaks¹.  Some of the supporting software is
>sufficiently non-obvious to install for those of us who haven't yet
>studied the intricacies of TCL module management, that I believe the
>REQADM installation instructions should cover the process in detail.

We're trying, with each release, to both document the process better,
and to make the process less daunting to begin with.  We think that
improved a bit in 1.3, but there's obviously more room for improvement.

>The change to a relational data base for all configuration info and
>tickets will be welcome.  The number and opacity of the configuration
>files to edit or create from scratch in order to get to where one can
>see what REQADM looks like is downright scary.  I tried to do it with
>as few changes to the distributed files as possible, and really
>thought I did everything, and did it right, but I guess I haven't,
>because xreqadm gives me lots of "Unable to look up token" dialogs,
>and dumps core during attempts to create or edit tickets.  I'll just
>have to go through the whole process again, I guess.

Hm.  The process is too hard, yes, but I was able to install the
whole thing on FreeBSD without changing any of the config files
(I think--or at least very little change) and got it to run.  I 
wonder what else might be giving you that trouble, if you're not
actually deleting any reqadm.conf records...

>¹ For instance, c++ has to be called with "-Wno-deprecated -fpermissive"
>  to stop it complaining about old-fashioned code, and to make it let
>  the following gem be a warning, and not an error (in many places):

Sigh.  It seems like with every release of GCC there's a new idea about
what's depricated, what's a warning, etc.  I didn't get much, if any,
complaints from the stock GCC on FreeBSD 4.8, so it's interesting what
difference there is between those versions of GCC.

>  For those who, like me, find that message less than lucid, it means
>  that if you're going to access characters in String objects using
>  "something[n]", then 'n' must be a long, not an int.  :-)

I'll look at that.

thanks for the feedback,
steve