Re: Which namespace for a build system?
[EMAIL PROTECTED] (Sam Vilain) writes: > A. Pagaltzis wrote: > > The question I'd ask is, is there established Computer Science > > terminology for the problem a dependency solver addresses? That > > probably requires determining what kind of field the problem > > falls into. I have a hunch that that would be AI. > > How about a "Dependancy Algorithm" ? :-) I remember reading something in Knuth (possibly somewhere in vol 3, I've got rid of my Knuths... :( ) about the relationship between dependency solving and partial ordering of sets. He presented a very simple algorithm there to do the solving. -- You are in a maze of little twisting passages, all alike.
Re: Which namespace for a build system?
A. Pagaltzis wrote: The question I'd ask is, is there established Computer Science terminology for the problem a dependency solver addresses? That probably requires determining what kind of field the problem falls into. I have a hunch that that would be AI. How about a "Dependancy Algorithm" ? :-) http://search.cpan.org/dist/Algorithm-Dependency/ -- Sam Vilain, sam /\T vilain |><>T net, PGP key ID: 0x05B52F13 (include my PGP key ID in personal replies to avoid spam filtering)
Re: Which namespace for a build system?
* Khemir Nadim <[EMAIL PROTECTED]> [2004-08-27 12:35]: > So my question boild down to this. Where do we put development, > dependencies, dev tools, build systems. What ever is suggested > I'll have hell of a time going through all the code and change > it (yes I do have a bunch of PBS::XX::YY::Sub() because I don't > specialy like the, very absurd, poluting policy modules have) I think you're not asking the right question yet. A dependency solver is not something useful purely for development. You can use it in a lot of generation tasks that don't involve source code. The question I'd ask is, is there established Computer Science terminology for the problem a dependency solver addresses? That probably requires determining what kind of field the problem falls into. I have a hunch that that would be AI. I admit I have been too lazy to attempt answering the question myself, so I resorted to explaining how I would go about it. :-) Regards, -- Aristotle "If you can't laugh at yourself, you don't take life seriously enough."
Re: Which namespace for a build system?
I agree with you. A build system is no more than a dependency system with some fluff around. The fluff, in this case, is 10% of the code. Say I put those 10% under PBS as it is an application. I still have a problem finding out where to put the 90% left because some smart guy decided that Devel is for perl development (rule that is broken half a million times) and that there is no other top level place for this kind of module. I'd start a new space but I'd rather start something that is going to be used bu other (or PBS is as good) So my question boild down to this. Where do we put development, dependencies, dev tools, build systems. What ever is suggested I'll have hell of a time going through all the code and change it (yes I do have a bunch of PBS::XX::YY::Sub() because I don't specialy like the, very absurd, poluting policy modules have) Cheers, Nadim. "A. Pagaltzis" <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > > A build system is an app but a dependency system is not. Even > > if it was to be classified as an app, I think we should have a > > root for build systems as there are at least three or four > > modules that would fit there. > > Well, quite a few applications or module suites ended up on CPAN > as a set of generic, regularly named modules, besides those > specific to the app, which got their own TLNS. > > So you might abstract your dependency management code into a (set > of) module(s) used by your app, where the app goes in its own > TLNS but the modules go wherever appropriate. > > This seems to apply to any application going on CPAN which > actually tackles problems not previously solved (as opposed to > apps which mainly glue together existing modules).
Re: Which namespace for a build system?
* Khemir Nadim <[EMAIL PROTECTED]> [2004-08-24 08:44]: > "Randy W. Sims" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > > I'm going to suggest that it is reasonable for an > > "application" of this sort to have its own namespace. It has > > a very specific use, and it is not generally applicable to > > other perl apps. > A build system is an app but a dependency system is not. Even > if it was to be classified as an app, I think we should have a > root for build systems as there are at least three or four > modules that would fit there. Well, quite a few applications or module suites ended up on CPAN as a set of generic, regularly named modules, besides those specific to the app, which got their own TLNS. So you might abstract your dependency management code into a (set of) module(s) used by your app, where the app goes in its own TLNS but the modules go wherever appropriate. This seems to apply to any application going on CPAN which actually tackles problems not previously solved (as opposed to apps which mainly glue together existing modules). Regards, -- Aristotle "If you can't laugh at yourself, you don't take life seriously enough."
Re: Which namespace for a build system?
"Randy W. Sims" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > I'm going to suggest that it is reasonable for an "application" of this > sort to have its own namespace. It has a very specific use, and it is > not generally applicable to other perl apps. A build system is an app but a dependency system is not. Even if it was to be classified as an app, I think we should have a root for build systems as there are at least three or four modules that would fit there. > I don't like the name PBS. Probably because, if you mention it anywhere > in the U.S., people the of the "Public Broadcasting Corp", a publicly > funded educational TV broadcasting network. PBS is for Perl Build System, I thought about Perl Make System but it was even worse. The leftish part of me like the idea of peoples money used to educate them instead for entertaining them as in the Roman's time , Except if your PBS is bad of course. > I can just about guarantee that it is not going to be used without some > documentation. I suggest it is useless to post it without docs, and > possibly a couple of samples. Samples are not a problem and with the huge amount of perl modules not documented or very poorly documented, it won't stand out ;-) The documentation is high on my priority list. Just before a complete refactoring to allow new types of optimizations (the third refactoring for PBS) > > One advantage of PBS is that it is quite fun to use and build debugging is > > one of the base for the program. > Hey, that's two ;-) Right. Let me know your opinion when you have had a look at the slides. Cheers, Nadim.
Re: Which namespace for a build system?
[ Actually, I'm going ahead and CC'ing the list because I'm going to suggest something that others will probably disagree with ;-) ] Nadim Khemir wrote: -Original Message- Is this a build system for perl modules or a generic build system? Is it an application or a library? Is the documentation available; I'd like to learn more about it. It' a generic build system aimed at replacing gmake, cons and the like. I'ts a meta-build system, a nice name to tell that it is not complete :-). I'm going to suggest that it is reasonable for an "application" of this sort to have its own namespace. It has a very specific use, and it is not generally applicable to other perl apps. I don't like the name PBS. Probably because, if you mention it anywhere in the U.S., people the of the "Public Broadcasting Corp", a publicly funded educational TV broadcasting network. PBS is a set of modules that let you build a build system. Since it's written in perl, you can add your own libraries and even have your own syntax if you wish to but the "plain" syntax is perl and it looks rather good and easy. The best doc to start with is the presentation I gave at "perl nordic workshop" the slides are on their site. In the unix perpetual tradition, the documentation is the code. Seriously, the documentation that is available is very old and very confusing. It was my goal to re-document the system this summer but I simply didn't. As there are only 2 or 3 users for the system and I know them, we haven't had the necessity to document more (the system is easy to understand as it is rule based). I want to release the system to see if there are other are interrested and in that case I will write a proper documentation. I can just about guarantee that it is not going to be used without some documentation. I suggest it is useless to post it without docs, and possibly a couple of samples. PBS is reseach project that turned wellbut I still want to do some research (like iontegration between CM and build systems) One advantage of PBS is that it is quite fun to use and build debugging is one of the base for the program. Hey, that's two ;-)
Re: Which namespace for a build system?
khemir nadim wrote: I'm going to polute witha new top level namespace! PBS:: Don't anyone have any idea of where we should put this type of modules? Is this a build system for perl modules or a generic build system? Is it an application or a library? Is the documentation available; I'd like to learn more about it. Randy. Devel:: Devel::Build:: Build:: App::BuildSystem I'd appreciate some input. Cheers, Nadim.
Re: Which namespace for a build system?
I'm going to polute witha new top level namespace! PBS:: Don't anyone have any idea of where we should put this type of modules? Devel:: Devel::Build:: Build:: App::BuildSystem I'd appreciate some input. Cheers, Nadim.
Which namespace for a build system?
Hi all, I hope you all had a nice summer vacation. I finally decided myself to release my build system as a developpers release. I am still having lots of problems deciding what licence to take but I came to understand that no one else will ever use it if I continue hidding it on my disk. I once describe it as: PBS is "rather" advanced (and big, around 400 Kb in 30 modules): - superset of perl - ** rule based ** - hierarchical - builds in heterogeneous env. - parrallel build (working on it right now) - a ton of debugging switches - graph output - perl debugger support - digest - triggers - post build rulles - node attributes - builds the full dependency tree - hierarchical configuration - separate rule namespace - is a set of modules reusable from within a script A presentation of the build system can be found at http://perlworkshop.dk/2004/files/presentations/pbs_slides.tar.gz (the tar file is not well behaved :-( and will expand in the current directory) Right now the modules are under "PBS". the other "build" sytems are anchored at diffrent places or not anchored at all.I would have like to have it placed under Devel::Build but the devel anchor is for perl development (though I and other have a modules there that have nothing to do with perl development). Any Comment, recommendations? For those who appreciate order and would like to have CPAN more organized I'd suggest a look at the most silly module ever: http://search.cpan.org/~jmcnamara/Your-Momma-0.01/lib/Your/Momma.pm. Cheers, Nadim.
