You are viewing a plain text version of this content. The canonical link for it is here.
Posted to rivet-dev@tcl.apache.org by Damon Courtney <da...@tclhome.com> on 2013/07/02 22:53:40 UTC

Installation

When building Apache, Tcl and Rivet from source, I always have to build Rivet with:

./configure --with-apr-config=/usr/local/apr/bin/apr-1-config

Else the Rivet build fails because it can't find apr.h.  I built and installed the APR package in its default place, so this is where it wants to live.  Can we make Rivet's configure script check for this?

Also, just a note, but the tclrivet package needs an update to the parser to grok the new <?= ?> construct.  Not a big deal, but I just noticed it.

So, with 2.1.2, we don't install packages at all by default?  The user has to explicitly call 'make install-packages' to get them?  What was the reason behind this?  Call me crazy, but the point of most installations today is to install all of the packages but load on demand, which is what we were already doing.

D
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org


Re: Installation

Posted by Brice Hamon <no...@gmail.com>.
Hi Damon,

On Opensuse 12.1, I didn't have this problem as apr-1-config is installed
under /usr/bin/apr-1-config that's why.
Agree for the make install-packages, I ran into it this one this morning.

Did you get to run the tests successfully? I cannot succeed so far but
still trying.
Brice.


On Tue, Jul 2, 2013 at 4:53 PM, Damon Courtney <da...@tclhome.com> wrote:

> When building Apache, Tcl and Rivet from source, I always have to build
> Rivet with:
>
> ./configure --with-apr-config=/usr/local/apr/bin/apr-1-config
>
> Else the Rivet build fails because it can't find apr.h.  I built and
> installed the APR package in its default place, so this is where it wants
> to live.  Can we make Rivet's configure script check for this?
>
> Also, just a note, but the tclrivet package needs an update to the parser
> to grok the new <?= ?> construct.  Not a big deal, but I just noticed it.
>
> So, with 2.1.2, we don't install packages at all by default?  The user has
> to explicitly call 'make install-packages' to get them?  What was the
> reason behind this?  Call me crazy, but the point of most installations
> today is to install all of the packages but load on demand, which is what
> we were already doing.
>
> D
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
> For additional commands, e-mail: rivet-dev-help@tcl.apache.org
>
>

Re: Installation

Posted by Rob Sciuk <ro...@controlq.com>.

Actually, there is a tool which can be made to return the path for the 
LD_LIBRARY, the INCLUDES, and the various AUTOCONF stuff used to build the 
Apache library.  This need only be reference in the Tcl makefile for this 
to occur, but the path to the tool must be known ... (Sorry for not having 
the details to hand, it has been a while since I used the libApr in a 
project).

Cheers,
Rob.


On Tue, 2 Jul 2013, Damon Courtney wrote:

> Date: Tue, 2 Jul 2013 15:53:40 -0500
> From: Damon Courtney <da...@tclhome.com>
> To: "<ri...@tcl.apache.org>" <ri...@tcl.apache.org>
> Subject: Installation
> 
> When building Apache, Tcl and Rivet from source, I always have to build Rivet with:
>
> ./configure --with-apr-config=/usr/local/apr/bin/apr-1-config
>
> Else the Rivet build fails because it can't find apr.h.  I built and installed the APR package in its default place, so this is where it wants to live.  Can we make Rivet's configure script check for this?
>
> Also, just a note, but the tclrivet package needs an update to the parser to grok the new <?= ?> construct.  Not a big deal, but I just noticed it.
>
> So, with 2.1.2, we don't install packages at all by default?  The user has to explicitly call 'make install-packages' to get them?  What was the reason behind this?  Call me crazy, but the point of most installations today is to install all of the packages but load on demand, which is what we were already doing.
>
> D
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
> For additional commands, e-mail: rivet-dev-help@tcl.apache.org
>
>
>

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=
Robert S. Sciuk		http://www.controlq.com		259 Simcoe St. S.
Control-Q Research	tel: 905.706.1354		Oshawa, Ont.
rob@ControlQ.com					Canada, L1H 4H3

---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org


Re: Installation

Posted by Massimo Manghi <ma...@unipr.it>.
Hi Damon

On 07/02/2013 10:53 PM, Damon Courtney wrote:
> When building Apache, Tcl and Rivet from source, I always have to
> build Rivet with:
> 
> ./configure --with-apr-config=/usr/local/apr/bin/apr-1-config
> 
> Else the Rivet build fails because it can't find apr.h.  I built and
> installed the APR package in its default place, so this is where it
> wants to live.  Can we make Rivet's configure script check for this?
> 

I thought it did

AC_DEFUN([APR_HANDLING],[
  AC_MSG_CHECKING(for Apache apr)
  AC_ARG_WITH(
   apr_config,
    [  --with-apr-config=FILE     apr portable apr-1-config path],
     [if test -x "${with_apr_config}"; then
         apr_found="${with_apr_config}"
     fi]
         ,
    [if test -x "${apache_base}/bin/apr-1-config" ; then
 ....

])

why didn't it work for you?

> Also, just a note, but the tclrivet package needs an update to the
> parser to grok the new <?= ?> construct.  Not a big deal, but I just
> noticed it.
> 

Again I thought it did

Adding branch 2.1
------------------------------------------------------------------------
r1337938 | mxmanghi | 2012-05-13 19:17:12 +0200 (Sun, 13 May 2012) | 9 lines

    * rivet/packages/tclrivet/tclrivetparser.tcl: Tcl parser implements
new shorthand echo syntax (closes bug #53217)

in fact

proc tclrivetparser::parse { data outbufvar } {
.....
    while {$i < $len} {
        incr i
        set cur $next
        set next [string index $data $i]
        if { $inside == 0 } {
            # Outside the delimiting tags.
            if { $cur == [string index $starttag $p] } {
                incr p
                if { $p == [string length $starttag] } {

                    if {$next == "="} {
#                       puts stderr "shorthand begin detected"
                        append outbuf "\"\n $outputcmd "
                        set shorthand   1
                        incr i
                        set next [string index $data $i]
                    } else {
                        append outbuf "\"\n"
                    }
....

IIRC it should be working, but admittedly there is no test for
tclrivetparser::parse in the test suite, only the C parser is tested.

> So, with 2.1.2, we don't install packages at all by default?  The
> user has to explicitly call 'make install-packages' to get them?
> What was the reason behind this?  Call me crazy, but the point of
> most installations today is to install all of the packages but load
> on demand, which is what we were already doing.
> 

I understand, my choice is arguable and I would have liked feedbacks
when I proposed it
http://mail-archives.apache.org/mod_mbox/tcl-rivet-dev/201306.mbox/%3C51B5E2F6.2030109%40unipr.it%3E

A better approach would have been to preserve 'make install' as an
'install everything' target and split it into 2 depends on
'install-packages' and 'install-binaries' targets. I think we could go
that way quite safely and I will get the blame for not having thought of
it on time and for having gotten out a lame version of rivet.

The proposal came up from my extra engagement as rivet package
maintainer for Debian/Ubuntu. More specifically: Ubuntu is going a
multi-architecture organization which, needless to say, means
arch-independent files can be shared between arch-specific
libraries/executables. Debian itself is stressing out the separation
between arch-independent and arch-dependent builds, I presume to
partially relieve their hardware from the burden of building the same
packages to the same extent for each supported architecture.

-- 
-- Massimo Manghi

Dipartimento di Neuroscienze
Unità di Biofisica e Fisica Sanitaria
via Volturno 39
43125 Parma

---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org