with our new move to Subversion, we apparently lost the ability to easily link submodules into a single higher-level module (such as icecast)...in the old CVS repository, icecast consisted of a handful of modules, icecast and other modules, which are shared by icecast and ices : avl httpp log net thread timing in the new Subversion repository, they are still kept as separate modules, however, there is currently not a way to "link related modules" so you could do a single checkout of "icecast" and have it get the icecast module, plus all related sub-modules. Please correct me if I'm wrong. So, as a result, if you currently check out the icecast trunk in the SVN repository, you have to manually check out the sub-modules (and you have to make sure you do them in the right locations. A possible solution was to include a simple "check out" script which has the dependencies and directory requirements embedded in it.. my proposal is that we take all the icecast/ices shared modules (which currently consist of AVL, HTTPP, LOG, NET, THREAD, TIMING) and bundle them into a single library, which I propose to be called, libicecommon. This library will be kept separately and will be required to be installed BEFORE icecast is built. Similar to the dependency on libshout that ices has. This would add another library dependency to icecast (currently, we have dependencies for libcurl (optional), libxml2, pthread, libogg, and libvorbis). This change would add another library (libicecommon in this case) to the dependency list. This would also have the same implication on ices. I do not believe any other XIPH modules/projects share these modules. Feedback ? oddsock <p>--- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
On Friday, 02 April 2004 at 22:19, oddsock wrote:> my proposal is that we take all the icecast/ices shared modules (which > currently consist of AVL, HTTPP, LOG, NET, THREAD, TIMING) and bundle them > into a single library, which I propose to be called, libicecommon. > ThisI agree with you up to this point - having all these tiny modules in one place would be a lot more convenient.> library will be kept separately and will be required to be installed BEFORE > icecast is built. Similar to the dependency on libshout that ices has.But I'm not sure about this. There's nothing in those libraries of any use to anything but icecast code itself, so I don't see why it should be installed on users' systems. It's true that the code is used in a couple of different icecast places, but I don't think it's large enough to warrant being an additional end-user dependency. As far as I can tell this just sacrifices user convenience for developer convenience, which IMHO is usually a bad trade. I'd vote to merge the modules into one, but otherwise either keep the status quo until subversion gets upgraded, or maybe add a checkout script. It's a nuisance to check out three things (iceutil, m4, and your project) to work on one, but it's not that much of a nuisance, and checkout isn't a frequent operation. -b --- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
On Fri, Apr 02, 2004 at 10:19:43PM -0600, oddsock wrote:> in the new Subversion repository, they are still kept as separate modules, > however, there is currently not a way to "link related modules" so you > could do a single checkout of "icecast" and have it get the icecast module, > plus all related sub-modules. Please correct me if I'm wrong.It's a little more complicated than that, but essentially true.> my proposal is that we take all the icecast/ices shared modules (which > currently consist of AVL, HTTPP, LOG, NET, THREAD, TIMING) and bundle them > into a single library, which I propose to be called, libicecommon. This > library will be kept separately and will be required to be installed BEFORE > icecast is built. Similar to the dependency on libshout that ices has.I agree combining the helper modules makes sense. However, I'd suggest supporting a static link to a local build within the ice* source trees, so you can still do a separate checkout and have things 'just work'. What about the components that are shared between libshout and ice*? Would we just be making those interfaces public so they could be explicitly shared through libicecommon? This also doesn't help with the 'm4' module.> This would add another library dependency to icecast (currently, we have > dependencies for libcurl (optional), libxml2, pthread, libogg, and > libvorbis). This change would add another library (libicecommon in this > case) to the dependency list. This would also have the same implication on > ices. I do not believe any other XIPH modules/projects share these modules.No, it's just the icecast-related projects. -r --- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
At 12:42 AM 4/3/2004, you wrote:>On Fri, Apr 02, 2004 at 10:19:43PM -0600, oddsock wrote: >I agree combining the helper modules makes sense. However, I'd suggest >supporting a static link to >a local build within the ice* source trees, so you can still do a separate >checkout and have >things 'just work'.what exactly are you referring to with a "static link" ?>What about the components that are shared between libshout and ice*? Would >we just be making those >interfaces public so they could be explicitly shared through libicecommon?not sure which components you are referring to.. icecast doesn't need libshout, ices does need libshout. Both ices and icecast need the modules I'm proposing combining into icecommon, but libshout does not. I guess probably what you are referring to is the dependency on libshout and what would become libicecommon. although there is no dependency between icecast and libshout, I wouldn't be adverse to encorporating libshout into icecommon, or we could encorporate all of icecommon into libshout. Looks like the only module that is currently NOT part of libshout is LOG. So it could be that we can solve this problem by simply : 1. Adding LOG to libshout 2. Adding libshout as a dependency for icecast. thoughts ?>This also doesn't help with the 'm4' module.yes, I agree, any ideas on that ? oddsock <p>--- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
At 11:10 AM 4/3/2004, you wrote:>But I'm not sure about this. There's nothing in those libraries of any >use to anything but icecast code itself, so I don't see why it should >be installed on users' systems. It's true that the code is used in a >couple of different icecast places, but I don't think it's large >enough to warrant being an additional end-user dependency. As far as I >can tell this just sacrifices user convenience for developer >convenience, which IMHO is usually a bad trade.well, one of the main reasons for making it a separate library is the fact that both icecast AND ices use it...otherwise, I'd suggest just including it with the icecast core..... oddsock <p>--- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
> > library will be kept separately and will be required to be installed BEFORE > > icecast is built. Similar to the dependency on libshout that ices has. > > But I'm not sure about this. There's nothing in those libraries of any > use to anything but icecast code itself, so I don't see why it should > be installed on users' systems. It's true that the code is used in a > couple of different icecast places, but I don't think it's large > enough to warrant being an additional end-user dependency. As far as I > can tell this just sacrifices user convenience for developer > convenience, which IMHO is usually a bad trade. > > I'd vote to merge the modules into one, but otherwise either keep the > status quo until subversion gets upgraded, or maybe add a checkout > script. It's a nuisance to check out three things (iceutil, m4, and > your project) to work on one, but it's not that much of a nuisance, > and checkout isn't a frequent operation.Grouping the modules together is not a problem, however I agree with Brendan here that they should still be linked into icecast and ices statically both for 'creating less dependency' reasons and for removing dynamic link and code size overhead for such small little things (though this might be important for both the sock and thread parts since those are called frequently). jack. --- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
On Mon, Apr 05, 2004 at 11:49:45AM +1100, Michael Smith wrote:> I'm told (by Ralph) that subversion _does_ allow this, though it's not > currently set up. I'd prefer that solution, as it's simpler for users to > figure out.This is what I meant by 'slightly more complicated than that'. ubversion does have an auto-check-out-these-modules hack. It still treats them as separate checkouts though, so you have remember to commit changes there separately. This is considered a bug upstream, and probably isn't a big deal, since updates do work properly. The problem is, we use http: urls for read-only access and svn+ssh: urls for read-write access. And the auto-checkout can't remap. So we could use it for one and make the other do things by hand. We could use http: for read-write as well. This means using ssl certificates for authentification. We didn't do that because everyone already had ssh access set up and I didn't want to bother you all. Aside from no one having written an ssl-agent, I can't think of a reason we couldn't do that instead. -r --- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
On Saturday 03 April 2004 14:19, oddsock wrote:> with our new move to Subversion, we apparently lost the ability to easily > link submodules into a single higher-level module (such as icecast)...in > the old CVS repository, icecast consisted of a handful of modules, > > icecast > and other modules, which are shared by icecast and ices : > avl httpp log net thread timing > > in the new Subversion repository, they are still kept as separate modules, > however, there is currently not a way to "link related modules" so you > could do a single checkout of "icecast" and have it get the icecast module, > plus all related sub-modules. Please correct me if I'm wrong.I'm told (by Ralph) that subversion _does_ allow this, though it's not currently set up. I'd prefer that solution, as it's simpler for users to figure out. If this is wrong, and we can't do this, then I think your proposal is an excellent idea. Mike --- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.