[livesupport-dev] changing to full autoconf-style setup - Airtime Development Discussions on Sourcefabric Forum

import

mainly to Tomas & Sebastian,

I've managed to change most of our modules, tools and the master make
environment to an autoconf-style setup. the main idea is that in any
directory containing anything useful, the following would generally work:

bin/autogen.sh (only if from CVS)
./configure
or
./tmp/configure
make
make install

and that specific module / component / product / tool whould compiled
and installed into the target directory and with the specific flags
specified by the configure options.

the main point of this excersise is that the following would work in any
tool and module directory:

./bin/autogen.sh
./tmp/configure --prefix=/some/prefix
make
make install

and that the given component would be installed under /some/prefix, with
the usual filesystem hierarchy according to the standard:

/some/prefix/bin - binaries
/some/prefix/etc - config files
/some/prefix/include - include files
/some/prefix/lib - libraries
/some/prefix/var - data files (including files served by the web server)
/some/prefix/tmp - temporary files

and that the installation would be more or less workable, with the sane
default settings, etc.

as the changes are quite big, and they aren't ready, but more of us need
to work on it, I've created a new branch in the CVS, named
autoconf-install. to access this branch, check out our sources like the
following:

cvs co -r autoconf-install livesupport

I tried to update the PHP modules as well to behave autoconf-style, but
I'm lacking some knowledge in this regard. therefore I'd ask Tomas &
Sebastian to take a look at what I've done, and complete the transition
for each PHP module, and for the tools/pear libraries as well (I haven't
touch that as yet).

when this is finished, I can finish tidying up the master makefile and
configure script (and merge the changes back to the main trunk), so that
basically one can really say at the livesupport main directory:

./configure --prefix=/opt/livesupport
make
make install

(and this is what would enable proper packaging on Debian and other
systems...)

some notes:

I've already added library detection to the master configure script - so
if a library we use is available already on the system (in a sufficient
version), it's not going to get compiled. this can shorten the
compilation time on systems that already have up-to-date packages that
we need.

one of the implied changes is that the install and uninstall targets in
the scheduler and some other packages were renamed to init and deinit,
as install should be used for installation

some PHP modules make some funny stuff when just invoking make on them,
like installing database tables, etc. invoking make without any options,
or invoking make all should do any compilation and linking necessary
(basically building the module). for PHP, this is basically a noop. see
the standard makefile targets in the GNU coding standards document:

http://www.gnu.org/prep/standards/html_node/Standard-Targets.html#Standard-Targets

------------------------------------------
Posted to Phorum via PhorumMail

import

With your autoconf style changes, if I was to checkout the new branch
would I be able to do any testing/building? Or should I wait for it to
merge back with the main branch.

I am going to go through the included libraries in the main branch
download and ensure that they are available for debian. I will be going
against the "testing" side of debian.

dmz

Ákos Maróy wrote:

>mainly to Tomas & Sebastian,
>
>
>I've managed to change most of our modules, tools and the master make
>environment to an autoconf-style setup. the main idea is that in any
>directory containing anything useful, the following would generally work:
>
>bin/autogen.sh (only if from CVS)
>./configure
>or
>./tmp/configure
>make
>make install
>
>
>and that specific module / component / product / tool whould compiled
>and installed into the target directory and with the specific flags
>specified by the configure options.
>
>the main point of this excersise is that the following would work in any
>tool and module directory:
>
>./bin/autogen.sh
>./tmp/configure --prefix=/some/prefix
>make
>make install
>
>and that the given component would be installed under /some/prefix, with
>the usual filesystem hierarchy according to the standard:
>
>/some/prefix/bin - binaries
>/some/prefix/etc - config files
>/some/prefix/include - include files
>/some/prefix/lib - libraries
>/some/prefix/var - data files (including files served by the web server)
>/some/prefix/tmp - temporary files
>
>and that the installation would be more or less workable, with the sane
>default settings, etc.
>
>
>as the changes are quite big, and they aren't ready, but more of us need
>to work on it, I've created a new branch in the CVS, named
>autoconf-install. to access this branch, check out our sources like the
>following:
>
>
>cvs co -r autoconf-install livesupport
>
>
>I tried to update the PHP modules as well to behave autoconf-style, but
>I'm lacking some knowledge in this regard. therefore I'd ask Tomas &
>Sebastian to take a look at what I've done, and complete the transition
>for each PHP module, and for the tools/pear libraries as well (I haven't
>touch that as yet).
>
>when this is finished, I can finish tidying up the master makefile and
>configure script (and merge the changes back to the main trunk), so that
>basically one can really say at the livesupport main directory:
>
>./configure --prefix=/opt/livesupport
>make
>make install
>
>
>(and this is what would enable proper packaging on Debian and other
>systems...)
>
>
>some notes:
>
>
>I've already added library detection to the master configure script - so
>if a library we use is available already on the system (in a sufficient
>version), it's not going to get compiled. this can shorten the
>compilation time on systems that already have up-to-date packages that
>we need.
>
>one of the implied changes is that the install and uninstall targets in
>the scheduler and some other packages were renamed to init and deinit,
>as install should be used for installation
>
>some PHP modules make some funny stuff when just invoking make on them,
>like installing database tables, etc. invoking make without any options,
>or invoking make all should do any compilation and linking necessary
>(basically building the module). for PHP, this is basically a noop. see
>the standard makefile targets in the GNU coding standards document:
>
>http://www.gnu.org/prep/standards/html_node/Standard-Targets.html#Standard-Targets
>
>
>
>
>

------------------------------------------
Posted to Phorum via PhorumMail

import

At 20:41 25.07.2005, you wrote:
>mainly to Tomas & Sebastian,
>
>
>I've managed to change most of our modules, tools and the master make
>environment to an autoconf-style setup.

one thing that sebastian mentioned but somhow got lost in the install
preparation: the html interface should sit in the /admin/ folder - as any
software does it these days. the /htmlUI/ folder - i don't even know who
ever thought of that name.

akos, could you make that change?

Micz Flor - micz@mi.cz

content and media development http://mi.cz
------------------------------------------------------------------
http://www.campware.org -- http://www.redall.de -- http://suemi.de
------------------------------------------------------------------

------------------------------------------
Posted to Phorum via PhorumMail

import

David M. Zendzian wrote:
> With your autoconf style changes, if I was to checkout the new branch
> would I be able to do any testing/building? Or should I wait for it to
> merge back with the main branch.

not really. the reason I created the branch is that the changes I
committed back are not full, they actually break the release process

> I am going to go through the included libraries in the main branch
> download and ensure that they are available for debian. I will be going
> against the "testing" side of debian.

excellent!

Akos

------------------------------------------
Posted to Phorum via PhorumMail

import

Micz Flor wrote:
> one thing that sebastian mentioned but somhow got lost in the install
> preparation: the html interface should sit in the /admin/ folder - as
> any software does it these days. the /htmlUI/ folder - i don't even know
> who ever thought of that name.

it doesn't really matter where it sits, as the web server will have to
be told where to server it. according to the current install, it is
being server under /livesupport/

Sebastian did mention your idea of having LS on /admin, like
http://mi.cz/admin/ - but we both aggreed that it's not really a good
idea. Hijacking a generic term like 'admin' in the root of a server - it
seems quite rude to me, also counter-intuitive (admin of what?)

>
> akos, could you make that change?

I guess Sebastian could... The point is, each module should install
itself properly...

Akos

------------------------------------------
Posted to Phorum via PhorumMail

import

Hi,
mainly for Akos:
I'm sorry, but the autoconf-style changes are not fully clear to me -
unfortunately I've probably not enough knowledge about autoconf/autogen

a)
bin/autogen.sh on fresh cvs co -r autoconf-install have print this output:
... stripped ...
checking whether the compiler implements namespaces... yes
checking whether the Boost::DateTime library is available... no
not found boost library of sufficient version, will compile from our own
configure: error: cannot find install-sh or install.sh in \
/opt/livesupport_autoconf/tmp /opt/livesupport_autoconf/tmp/.. \
/opt/livesupport_autoconf/tmp/../..
Is something wrong on my side?

b)
in etc/Makefile.in the storageServer relevant line in modules_setup target:
cd ${STORAGE_SERVER_DIR}/tmp && ./configure --prefix=${prefix}
it call configure in tmp, but storageServer/tmp is empty, I guess that
configure in tmp will be created by storageServer/bin/autogen.sh -
autogen.sh have recursive calls to subdirs or somewhere are calls to
modules' and products' autogen.sh?

c)
From "Standard-Targets" document it's not clear to me in which target
should be initialized database structure - may I create "init" or "init_db"
target for it?
The "all" target sounds mnemotechnical, but you are right document says
"only compile" - it's probably designed mainly for compiled SW ... Wink

d)
Where do you think I should install storageAdmin executable scripts?
- I have chosen the usr/bin, because I think it shouldn't be mixed with
compiled binaries ...
OK?

I have tried to change tools/pear to autoconf style and it looks usable
- it will be committed after some tests ...

thanks

Tomas Hlava
th@red2head.com

On Mon, 25 Jul 2005 20:41:30 +0200

import

Tomas Hlava wrote:
> Hi,
> mainly for Akos:
> I'm sorry, but the autoconf-style changes are not fully clear to me -
> unfortunately I've probably not enough knowledge about autoconf/autogen
>
> a)
> bin/autogen.sh on fresh cvs co -r autoconf-install have print this output:
> ... stripped ...
> checking whether the compiler implements namespaces... yes
> checking whether the Boost::DateTime library is available... no
> not found boost library of sufficient version, will compile from our own
> configure: error: cannot find install-sh or install.sh in \
> /opt/livesupport_autoconf/tmp /opt/livesupport_autoconf/tmp/.. \
> /opt/livesupport_autoconf/tmp/../..
> Is something wrong on my side?

I'll look into it, but it would be more important for you to concentrate
on the PHP modules and tools/pear. (as I wrote earlier, the whole thing
is not ready yet...)

>
> b)
> in etc/Makefile.in the storageServer relevant line in modules_setup target:
> cd ${STORAGE_SERVER_DIR}/tmp && ./configure --prefix=${prefix}
> it call configure in tmp, but storageServer/tmp is empty, I guess that
> configure in tmp will be created by storageServer/bin/autogen.sh -
> autogen.sh have recursive calls to subdirs or somewhere are calls to
> modules' and products' autogen.sh?

see etc/configure.ac

again, the point is that any module would do the following properly:

./bin/autogen.sh
./tmp/configure --prefix=/some/prefix
make
make install

>
> c)
>>From "Standard-Targets" document it's not clear to me in which target
> should be initialized database structure - may I create "init" or "init_db"
> target for it?

sure

> The "all" target sounds mnemotechnical, but you are right document says
> "only compile" - it's probably designed mainly for compiled SW ... Wink

yes, it is, and it especially should change the system in general, like
creating database tables, etc.

>
> d)
> Where do you think I should install storageAdmin executable scripts?
> - I have chosen the usr/bin, because I think it shouldn't be mixed with
> compiled binaries ...
> OK?

prefix/bin is fine

OTOH, PHP file should be prefix/var/LiveSupport, instead of just
prefix/var (look at your own /var or /usr/var, for example)

>
> I have tried to change tools/pear to autoconf style and it looks usable
> - it will be committed after some tests ...

thanks!

Akos

------------------------------------------
Posted to Phorum via PhorumMail

import

import

I've commited autoconf-izing of storageServer, alib, archiveServer, storageAdmin
and tools/pear.
Unfortunately there probably will be problems yet ...

On Tue, 26 Jul 2005 10:42:17 +0200

import

On Tue, 26 Jul 2005 10:42:17 +0200

import

Tomas Hlava wrote:
> I have a chat with Sebastian and there have appeared a question:
> what's the reason for the 'LiveSupport' part in
> prefix/var/LiveSupport path?

well, look at your /var ...

this LS will be installed eventually, will be the system var directory,
where all other packages install their files. therefore it has to be
separated from the others somehow...

------------------------------------------
Posted to Phorum via PhorumMail

import

On Wed, 27 Jul 2005 18:35:58 +0200

import

Tomas Hlava wrote:
> thanks - it's clear now,
> although as I see, my /var doesn't contain any directory named by application,
> only general dirs as lib, lock, log, run ... Wink

but it does contain /var/www, /var/lib/postgresql and the like Smile

feel free to find another suitable name we should put our files under...

------------------------------------------
Posted to Phorum via PhorumMail

Howdy, Stranger!

Categories

Poll

Top Posters