Re: [jazzplusplus-devel] SF.net SVN: jazzplusplus:[620] web/htdocs/buildingtex2rtf/index.php

[Pete S. <pst...@gm...>]

DM = D.B. Moore
DM>>> I know I'm being painful asking this .... this being the case,
DM>>> then why bother invoking su for the wx build to install it
DM>>> in /usr/local ? That is to say, why don't we just install
DM>>> wx in the user's $HOME instead so that all 3 packages don't
DM>>> need root_priv at all? I'm only thinking of users who might
DM>>> not like having to work this out...(I think my mind mumbling
DM>>> 'consistent approach' or such and similar... <grin>)....I just
DM>>> linked tex2rtf into the wx289/bin path because I'm pathetically
DM>>> lazy. Shoot me if I'm getting annoying...

KC = Kevin Cosgrove
KC>> I package a lot of things, and nearly all of them default to
KC>> /usr/local for the default prefix; some default to /usr.
KC>> Installing as root is pretty standard. I'd say that anyone
KC>> who could build jazz++ and the prerequisites would likely
KC>> be able to alter the $PREFIX if they wanted to. I'll
KC>> advocate for /usr/local. --prefix=$HOME isn't too hard to do,
KC>> if desired.

DM> Oh yes, I agree.....all I'm saying is, the user becomes
DM> root to install the wx build anyway, so why not for
DM> tex2rtf as well? The way the tex2rtf build is presented,
DM> the 'unknowledgeable user' will  -need-  to alter their
DM> PATH in ~/.bash_profile anyhow before jazz will actually
DM> build, and again for the aforesaid 'unknowledgeable user',
DM> they made need a pointer to this if they don't actually
DM> know what's going wrong. As it stands now, the door is
DM> left wide open to a swag of 'jazz does not compile'
DM> emails, because, technically speaking, the build
DM> instructions are wrong. I do realize these emails are all
DM> hypothetical, what I'm talking about in reality does not
DM> exist -- the situation exists that so called
DM> 'unknowledgeable users' might happen along here, be willing
DM> to give it a try but in the same moment be totally reliant
DM> on following the instructions to-the-letter (c&p), and
DM> for all I know these people might not speak english as
DM> a first language or at all.
DM>
DM> Remember, I'm the one who wrote up the line in the web-docs
DM> which says that even unknowledgeable users should be able
DM> to build jazz from svn with as little effort as cutting &
DM> pasting the instructions on the web-site straight into their
DM> shells...this issue with tex2rtf actually breaks
DM> that premise.
DM> Right now, what I've cited is a lie...and I know it...I'm
DM> resting uneasy. My primary concern is accuracy of content,
DM> nothing more. Yes, people that are capable of building jazz
DM> presently can alter their path 'if they wanted to' -- the
DM> point really is that they **have** to, or the jazz build will
DM> fail.
DM>
DM> Myself...I really don't care at all - I will see an omission
DM> like this and quick as blink sort it out forthwith. That
DM> said, I will report it in the guise of this hypothetical
DM> 'unknowledgeable user', as an example of foresight. Granted,
DM> there might be less than a dozen people working with the
DM> current jazz++ right now.....right now, anyone who comes
DM> along and follows the online instructions, is headed for
DM> disappointment -- sometimes, you only get one shot at
DM> impressing users....'they can't even get the build
DM> instructions right'.
DM>
DM> That's what I'm saying, looking in my mirror.  Eventually,
DM> {release), tex2rtf has to go somewhere -- putting it in
DM> the same location as the jazz binary for the moment is fine
DM> by me -- this being the case, perhaps the web-docs should
DM> include lines somewhere (before build jazz), to add;
DM>
DM> export PATH=$HOME/Jazz++/TestInstall:$PATH
DM>
DM> to the user's  ~/.bash_profile
DM>
DM> Then this all goes away and the given instructions work
DM> 'out of the box' again. In theory, this should never be
DM> a problem until {release}, at which time this path
DM> addition would conflict with a system installed jazz in
DM> /usr or /usr/local and thus would need be removed. It's
DM> a lot nicer to be able to just type  'jazz'  at the
DM> prompt and get results too....imho.

I caused the problem by worrying about a potential user that may not 
have root access on a machine.  I faced this situation at work when a 
colleague attempted to install wxWidgets at a user site and didn't have 
root access.  I copied the instructions from a work web site I generated.

The autotools and autoconf in particular default to /usr/local as the 
installation location.  For wxWidgets, I like the idea of specifying 
/usr/local/wx{version} so that multiple versions can be loaded and I can 
wipe out the entire install by removing that directory.  Otherwise I 
would have to remove particular files in /usr/local/bin, /usr/local/lib, 
/usr/local/include... and this can be a pain if the user has other codes 
installed in these directories.  I'm not sure in wxWidgets has a "make 
uninstall" command, but even if it does, I don't want to rely on it as 
the user may erase their build directory.

So for now, I think I'll assume everyone that is building Jazz++ is a 
developer, or helping me debug problems and change the instructions to...

1. Assume the developer has root access and if they don't assume they 
are smart enough to deal with the "--prefix=..." configure option.
2. Use --prefix-/usr/local/wx289 for wxWidgets and have the user build 
and install both release and debug versions of the wxWidgets library.
3. Use the default prefix (/usr/local) for tex2rtf.  The only files that 
get installed are tex2rtf and tex2rtf_gui in the /usr/local/bin 
directory and this is usually included in the users path.  This code 
will use the release version of wxWidgets.  I don't want to deal with 
tex2rtf issues at this point.
4. Give instructions for both a debug and release build of Jazz++ and 
the developer can choose.

Does this sound OK?

I'd really prefer to work on the code instead of these instructions.  I 
still don't have it recording MIDI :-(

Pete