On Wed, Oct 1, 2008 at 2:08 PM, Giuseppe Scrivano <[EMAIL PROTECTED]> wrote: > Autotools don't offer the same flexibility of scons to handle external > resources. > > If we will decide to use scons only for plugins it will not make the > SConstruct file simpler (if not for few lines), because all the > libraries/headers checks must be done in any case.
the problem isn't the complexity of the SConstruct file > Manage plugins from the GUI is possible only when we will offer binaries > for them or simply making the GUI program a frontend to the scons > building system. > > Actually it is already used a .xml file to describe the plugin, what do > you think about package binaries as a simple .zip file? > We can add another rule in the SConstruct file to automatically do it > for us. The files list to include in the .zip can be maintained in the > same .xml file Yes, we can do this and manage the zip files with the GUI. > Another question, do we need a hierarchy for plugins like it is now or a > flat plugins/ directory can be enough? I think that at least the > "generic" category must be removed and these plugins added directly in > the plugins directory root. I think it's better now a flat plugin directory, because plugins are external entities and can be very different from each other, then I think it doesn't make sense create a hierarchy. > > Giuseppe > > > Daniele Perrone wrote: >> Hi everbody, >> >> At this moment in myserver there are two building systems, automake >> ecc for myserver core, and Scons I guess for plugins managment and >> building. I know that still now we can build myserver core using >> scons, but in my opinion it's a bad repetition that should be removed. >> Then, my idea is separate physically plugins building system and >> myserver core building system, maybe moving Sconstruct file in the >> plugins directory, and manage plugins from myserver not by a scripting >> way but just in the GUI. then, what do you thing about the plugin >> building system? Which is the better way to manage them? >> > > -- Perrone Daniele
