On Thu, 6 Jan 2011, Donn Washburn wrote:
>
> On 01/06/2011 08:18 PM, klaatu wrote:
>> On Thu, 6 Jan 2011, Donn Washburn wrote:
>>
>>> On 01/06/2011 12:11 PM, Christopher Sean Morrison wrote:
>>>> On Jan 6, 2011, at 12:53 PM, Donn Washburn wrote:
<snips />
>>> Well I have followed your request to try exec-prefix=${prefix} and
>>> completely
>>> reloaded a fresh cvs source. And have used nothing but autogen.sh and
>>> ./configure. After it built it I did "make -n install" and it is /bin
>>> still.
>>> I used my brlcad-conf-it script (which I can send you if you wish). I still
>>> think it is a autoconf version headache.
>>>
>>>
>>> Also this time it did build the src/options/tk and tcl Makefiles . ./misc/
>>>
>>> Here is a short output of make -n install and my config file.
>>>
>>> I feel it is a autoconfig new version problem.
>> I recently compiled brlcad-7.18.0.
>>
>> Usually when I compile (BRLCAD or anything else), I do something like
>> this:
>>
>> ./configure --help (and examine the options)
>>
>> echo "./configure --with-gnu-ld --with-x --enable-jove
>> --enable-optimized">CONFIG
>>
>> And to configure, I just commandline `cat CONFIG` and hit return.
>>
>> The default has been to install BRLCAD to /usr/brlcad and I'm not sure why
>> anyone would want to put it anyplace else, unless perhaps they wanted to
>> specify --prefix=/usr/brlcad-x.xx.x or perhaps --prefix=/usr/brlcad-y.yy.y
>> which gives good version control, and also keeps the BRLCAD libraries and
>> executables (and shares etc) out of main paths. This also helps avoid
>> versioning incompatibilities from creeping in. For example, the BRLCAD
>> tcl/tk etc is meant to be very helpful with BRLCAD but it might bork
>> anything else on your system which is expecting a somewhat different set
>> of capabilities or specific versions of tcl/tk. Just an example. So you
>> might as well just go with the defaults. Maybe write a little script to
>> run right before each use, something like
>>
>> ---->
>> #! /bin/bash
>> export MANPATH="$MANPATH:/usr/brlcad/man" # or /usr/brlcad-x.xx.x/man
>> export FB_FILE="/dev/Xl" # that "l" is a lower-case "L"
>> export LD_LIBRARY_PRELOAD="$LD_LIBRARY_PRELOAD:/usr/brlcad/lib"
>> export PATH="$PATH:/usr/brlcad/bin" # or /usr/brlcad-x.xx.x/bin whatever"
>>
>> If you want to go to the extreme effort of specifying --exec-prefix and
>> that sort of thing, errors creep in rapidly and generally you're better
>> off just specifying --prefix. Even if some distributions (Debian, Ubuntu
>> etc) prefer to put everything under --prefix=/usr
>> --sysconfdir=/etc/packagename --localstatedir=/var etc etc that's all very
>> good for things that are designed to play well together, such as GNOME or
>> a basic OS package load. But for "specialty" items such as BRLCAD you
>> might want to just go mostly with the defaults.
>>
>> Note that sometimes you need to specify --exec-prefix to be the same as
>> --prefix or you'll get the present problem of new executables going into
>> /bin rather than into #prefix/bin.
>>
>> Regards,
>>
> Thanks for the reply!
>
> I am almost certain that this problem is a openSuSE problem. I just
> compiled and install autogen 5.1.5. I again tried it and it seems the
> Makefiles and configure file are different.
You may wish to start documenting your progress, so to speak.
For example, give a --prefix and perhaps an --exec-prefix for each build
attempt. For example, try one with --prefix=/usr/brlcad-7.18.0-try1 and
try another with --prefix=/usr/brlcad-7.18.0-try2. Of course this will use
up some harddrive space but terabytes are cheap nowadays. ;)
Then you could compare Makefiles with something like
diff /usr/brlcad-7.18.0-try1/Makefile /usr/brlcad-7.18.0-try2/Makefile
and then you will _know_ rather than guess that the Makefiles are
different. Same thing for config.status and config.h if the particular
package has config.h.
If you send your diffs into an outfile, for example
diff /usr/brlcad-7.18.0-try1/Makefile /usr/brlcad-7.18.0-try2/Makefile
>DIFF-try1-try2
you keep a permanent record for your backtracking and research.
Sometimes 'diff' is a great learning tool. Once you know what you're
looking to find, so is 'grep'. Once you know how to use those together,
'patch' and even 'sed' (and/or 'awk) start looking to be potentially
pretty useful. Makefiles have their own special qualities (and syntax) and
the ones created by autogen/autoconf are "even more special", in a "riding
the short school bus" sort of way. Maybe try compiling some packages that
don't rely on autogen/autoconf to get a better handle on "human readable"
Makefiles. I recommend XEphem from clearskyinstitute.com as an example of
nice human-made Makefiles. It's easier to learn from people than from
machines, so to speak.
I haven't used openSuSE but I'm pretty familiar with Slackware, Debian,
CentOS, NetBSD and Mac OSX. The commonalities of any decent *NIX usually
outweigh the differences between distributions.
All of these distributions have their peculiarities... but the commonality
of *NIX makes it easy to install something like BRLCAD into a sort of
generic location. For lots of packages, they will default to install in
/usr/local and if all of the OS-specific packages are in /usr that will
make it easy to remove any non-effective installations without conflic or
damage to the general OS.
If openSuSE is trying to force non-standard conventions peculiar to the
OS, try to figure out how to over-ride that. Doing things the standard
way, first, makes for an easier learning curve. Then once you see the
'diffs', you can adjust for that as a matter of choice, rather than coping
with weirdness imposed on you. Best of luck!
Regards,
--
Be kind to your neighbors, even though they be transgenic chimerae.
------------------------------------------------------------------------------
Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web. Learn how to
best implement a security strategy that keeps consumers' information secure
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
BRL-CAD Users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/brlcad-users