latest CVS commit

> > they are definitely used. nothing about the
purpose of these directories
> > changed, just the contents, how they get populated
and when they get
> > used. what makes you think they are not used? my
guess is that they do
> > not show up in any list of sources, and i did not
add them to
> > EXTRA_DIST; previously, they were always populated
at configure-time.
> > they should just be added to EXTRA_DIST as the
./config tree, since the
> > contents are now static - they are not modified
during configure or
> > build.
> 
> I figured out that they were used by the simple
expedient of
> deleting them and trying to build.  I am beginning to
understand
> what changed, though I still don't know the reasons.

i outlined the reasons at the time. any multi-platform build
(e.g.
universal on OS X, or someone making a debian package for 3
different
CPUs) should not *have* to run configure 3 times: it should
be possible
to run configure once, and then run the appropriate (cross)
compiler 3
times. the original system did all the config/ tree setup at
configure
time, which prevents this approach to building and can lead
to builds
with different properties when it was not intended. the new
system
doesn't modify the config/ tree at configure time at all,
but does
compile-time selection of various parts of it.

> I am working on creating Makefile.am files for all
those directories.
> I guess I'll delete the os/aix and os/irix
directories, as they don't seem

i think that there is no reason to have a Makefile.am for
these
directories. just include ./config in EXTRA_DIST plus the
dist-hook as
mentioned by others. the directories are read-only

> those .svn/* files: use svk instead.  That works but we
still need

i don't understand how that could ever be seen as a
solution 

> The current sysdeps files only seem to work for x86 and
powerpc.
> What do you plan to do about all the other Debian
platforms?

personally, i don't really care too much about debian after
they made it
impossible to use several common (among music-oriented
users) audio
interfaces on their systems without some rather cumbersome
steps by the
user (they dropped any packages containing the firmware
required for
these cards because they define it as non-free). if they see
fit to make
such decisions on behalf of their user community, i am not
going to put
time into fitting in with their choices.

> I think we need to ask them what should be done. 
Robert Jordens
> was helpful before, making test packages and running
them through
> the build system using their "experimental"
repository.  I suspect they
> will want to continue supporting all the CPU types. 
Replacing a
> package with one that only supports a subset of their
platforms will
> surely be messy.

then someone who cares about this will have to fix it. given
that the
previous attempts to provide cross-platform-compilability
were, as you
note, almost certainly never actually tested, it appears to
me to be
pretty useless work. saying that JACK compiles for debian on
AIX just
appears to have no useful content to me at all.

> While discussing packaging, I'd like to make one more
plea that we
> adopt standard libtool-style library version numbers
for libjack.  This

they are not standard, and we will not be using libtool in
the future,
but i agree that we could adopt them. 

> is long overdue, and would help address the confusion
created by
> the distributions having to invent their own version
strings.  We

distributions do not have to do this, but some of them have
chosen to do
so.

> should use it to document all upwards or downwards
binary
> compatibility issues.

right, this is the sole motivation i can see for the
libtool-style
version numbers.

> Let's get this fixed ASAP.

whatever solution we adopt for the version numbers should be
accompanied
by a solution that works without libtool.




Using Tomcat but need to do more? Need to support web
services, security?
Get stuff done quickly with pre-integrated technology to
make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on
Apache Geronimo
http://sel.as-us.falkag.net/
sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Jackit-devel mailing list
Jackit-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jackit-dev
el

Hi Paul, Jack and others,

did someone say libtool -- time to disable the lurking mode
for a 
while I guess. 

On Wed, 5 Jul 2006, Paul Davis wrote:

>> While discussing packaging, I'd like to make one
more plea that we
>> adopt standard libtool-style library version
numbers for libjack.  This
> they are not standard, and we will not be using libtool
in the future,
> but i agree that we could adopt them.

++votes for agreeing a plan/roadmap for 1.0 libjack API/ABI
management.

>> is long overdue, and would help address the
confusion created by
>> the distributions having to invent their own
version strings.  We
> distributions do not have to do this, but some of them
have chosen to do
> so.

But they have to do something in order to avoid upgrading
all the libjack 
clients whenever libjack is updated. Whether you care for
Debian or not, 
still an excellent resource describing the problem space for
distributor's 
point of view is:

   http://www.netfort.gr.jp/~dancer/column/li
bpkg-guide/libpkg-guide.html

> whatever solution we adopt for the version numbers
should be accompanied
> by a solution that works without libtool.

Essentially libtool interface versioning is just one way to
manage the 
library sonames. It's easy to follow the same soname
selection rules even 
without using libtool. In other words, I think it's safe to
use libtool 
for now -- it can be later be dropped while still continuing
with the same 
library versioning policy.

But before any of that, the key thing is to decide what kind
of interface 
changes are expected for libjack 1.0. Will all 1.x releases
be ABI 
compatible with 1.0, and do we need a mechanism to add stuff
while 
maintaining ABI compatibility (the libtool 'age'
property)? If yes, I 
think it's just easiest to use libtool versioning.

Options: 1) 1.0 will define the ABI for 1.x release, just a
single soname 
(libjack-1.0) is needed, no need for libtool; or 2) no ABI
guarantees, 
each public release has its own ABI that may or may not be
backwards 
compatible (the current system). We'd need to tag soname
with the release 
version.

Using libtool and (1) are good for end-users and
distributors, while (2) 
makes it a lot easier to develop new features and fix past
mistakes. I 
guess the main question is 1.0 the JACK milestone when we
can move to 
(1/libtool), or do we reserve 2.0 for that...?

PS And whatever is decided should be documented in
README.developers,
    there's still the empty section with a 'TBD' under
library
    versioning policy in there. 

-- 
  links, my public keys, etc at http://eca.cx/kv

------------------------------------------------------------
-------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the
chance to share your
opinions on IT & business topics through brief surveys
-- and earn cash
http://www.techsay.com/default.
php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Jackit-devel mailing list
Jackit-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jackit-dev
el