View previous topic :: View next topic |
Author |
Message |
kris
Joined: 27 Mar 2004 Posts: 1494 Location: South Pacific
|
Posted: Thu Aug 18, 2005 5:19 pm Post subject: Re: Open source projects using Ares |
|
|
pragma wrote: | A slightly different way to go would be to teach Build how to create dependency-complete "source bundles" (a zip or jar would work great) of code that given program needs to compile. That way the source distribution would be a version-exact source tree for just that program, no more, no less. |
This would be a really useful thing for Build to do, regardless of the other concerns. How about it, Derek? |
|
Back to top |
|
|
Derek Parnell
Joined: 22 Apr 2004 Posts: 408 Location: Melbourne, Australia
|
Posted: Thu Aug 18, 2005 10:52 pm Post subject: Re: Open source projects using Ares |
|
|
kris wrote: | pragma wrote: | A slightly different way to go would be to teach Build how to create dependency-complete "source bundles" (a zip or jar would work great) of code that given program needs to compile. That way the source distribution would be a version-exact source tree for just that program, no more, no less. |
This would be a really useful thing for Build to do, regardless of the other concerns. How about it, Derek? |
Sure, no problems.
Just one thing though ...what do you mean?
This is a Java thing right - I don't do Java so I'm not sure what it is you are actually talking about. Anyone care to explain it to me? Use lots of examples and short sentences _________________ --
Derek
skype name: derek.j.parnell |
|
Back to top |
|
|
kris
Joined: 27 Mar 2004 Posts: 1494 Location: South Pacific
|
Posted: Fri Aug 19, 2005 8:19 am Post subject: Re: Open source projects using Ares |
|
|
Derek Parnell wrote: | kris wrote: | pragma wrote: | A slightly different way to go would be to teach Build how to create dependency-complete "source bundles" (a zip or jar would work great) of code that given program needs to compile. That way the source distribution would be a version-exact source tree for just that program, no more, no less. |
This would be a really useful thing for Build to do, regardless of the other concerns. How about it, Derek? |
Sure, no problems.
Just one thing though ...what do you mean?
This is a Java thing right - I don't do Java so I'm not sure what it is you are actually talking about. Anyone care to explain it to me? Use lots of examples and short sentences |
Java thing? Do you mean the executable Jar notion? No.
This is just a way to bundle up all the source code for any given project. Since Build constructs a complete dependency tree (or list) for the file(s) it is asked to 'build', then instead of compiling the files it could cause them to be bundled together into a zip (or whatever).
The benefits are thus:
1) Build could make it easy to 'package' the source files for a project, filtering out any files that are not actually used.
2) Build could make it easy to 'package' the library source files (and all their dependencies too). Only those library files within the dependency tree would be selected (as is done for the compile option today).
The combination would allow one to easily bundle all the modules used for a given project "as and when the author considered it operational". The recipients of said project can rest assured they will have a complete snapshot of full source necessary to rebuild.
This assumes, of course, that all source is available (no obj/lib files required). Even with this restriction, it would be a very handy tool. There are some issues here, but perhaps not insurmountable.
It's a packaging tool, as opposed to a compiling tool (perhaps it should be independent?). Does this explain the notion? Keep in mind that Eric may have had a different idea. |
|
Back to top |
|
|
pragma
Joined: 28 May 2004 Posts: 607 Location: Washington, DC
|
Posted: Fri Aug 19, 2005 8:23 am Post subject: Re: Open source projects using Ares |
|
|
Derek Parnell wrote: |
Sure, no problems.
Just one thing though ...what do you mean?
This is a Java thing right - I don't do Java so I'm not sure what it is you are actually talking about. Anyone care to explain it to me? Use lots of examples and short sentences |
Java has "Resource Bundles", but that's a completely different animal. :p
Say I have a little util (like Watcher), that I want to release as sourcecode.
[my code]
myutil.d
main.d
[lib X (v0.1b) code]
libx1.d
libx2.d
libx3.d
libx4.d
Now, while I'm finishing my code for release, the owners for "lib X" spring a suprise on me and go from Beta 1 to Release 1 overnight while I'm busy working on my project (*coughkriscough*). If I were to release just *my* sourcecode, I'd need some way for my users to get at Lib X Beta 1, which is no longer on the Lib X site. Bummer. Now I have to redo my code for Lib X Release 1, and so my project timeline gets all screwed up.
Now suppose that Build has the feature I suggested. I would simply do something like this:
Code: | Build myutil.d -zmytil.zip |
Which would generate a file called "mytil.zip" that contains the following files:
As it turns out, my utiltiy didn't need all four of the lib X files; Build discovered this as it was navigating the import statements in my code.
Now, all I have to do is put myutil.exe and mytiul.zip on my website and that's that. For here on out, no matter what version lib X moves on to, I know that I can seamlessly release products using whatever library versions my code requires. I've also passed that on to my users as all they need is *one* .zip file that contains everything they need. It also puts everything in the same source tree, as my users don't need to replace or move whatever versions of Lib X they already have.
The "last mile" is done in documentation for the sake of users. It would involve stating that what versions of other libraries it was built against, and what this means for security, maintainability, documentation etc.
... and so we make our way out of ".configure hell". _________________ -- !Eric.t.Anderton at gmail |
|
Back to top |
|
|
jcc7
Joined: 22 Feb 2004 Posts: 657 Location: Muskogee, OK, USA
|
Posted: Fri Aug 19, 2005 8:51 am Post subject: Re: Open source projects using Ares |
|
|
kris wrote: | This is just a way to bundle up all the source code for any given project. Since Build constructs a complete dependency tree (or list) for the file(s) it is asked to 'build', then instead of compiling the files it could cause them to be bundled together into a zip (or whatever). | I think there's a growing need for something like this for D. It'd be great if it were part of Build (I don't know if Derek is interested in undertaking this), but it could be a separate program, too. I've spend way too much time deciding how to organize the package whenever I've uploaded code before. And when I've downloaded someone else's code, I never seem to find what I expect where I expect. It's not that the contents of the archive are unorganized -- it's just that there's not a single convention that everyone follows. Having a tool to do the dirty work would be great! |
|
Back to top |
|
|
JJR
Joined: 22 Feb 2004 Posts: 1104
|
Posted: Fri Aug 19, 2005 9:49 am Post subject: |
|
|
I totally agree. Such a tool would be great for D. Anything that helps cure insanity is a huge plus!
And like Justin said, D appears quite conventionless in this regard.
-JJR |
|
Back to top |
|
|
pragma
Joined: 28 May 2004 Posts: 607 Location: Washington, DC
|
Posted: Fri Aug 19, 2005 11:07 am Post subject: |
|
|
Correction:
The above example should contain libx1.d libx2.d myutil.d and main.d.
The idea was to have a complete distro, rather than just the dependencies (although that wouldn't be bad either).
I'm glad that this concept has some positive replies. I may start offering my source packages like this on my next go-round, even if Build won't trim the fat form me. _________________ -- !Eric.t.Anderton at gmail |
|
Back to top |
|
|
saivert
Joined: 15 Aug 2005 Posts: 8 Location: Norway
|
Posted: Fri Aug 19, 2005 11:08 am Post subject: Cluttering up Build?? |
|
|
Cluttering up Build??
I do not think it is such a good idea to clutter up the Build utility.
Build.exe should be used for building projects only and not packaging things up.
I know most of you guys have Perl, so it should be easy to write your little "packager" yourself. I will have a try, have to look into the zlib Perl bindings or just call an external ZIP utility.
If a project depends heavily on a certain version of some library it should include the library with the source package. Most serious library makers offer previous versions of their libs anyway.
You can use Build with the -names option and then parsing this output to simplify some of the work (why reinvent the import directive parser if Build already does a good job??).
And the reference to Java's JAR files is somthing I am a bit puzzled about. It has nothing to do with this. _________________ - New at D, like it though - Attending Kongsberg Tekniske Fagskole (Computer technician course) - |
|
Back to top |
|
|
lgoss007
Joined: 13 Oct 2005 Posts: 20
|
Posted: Thu Oct 13, 2005 4:41 pm Post subject: |
|
|
Has a style been decided? Will the library use the D style guideline? I like it better than most guidelines (I dislike the WHOLE_UPPERCASING_OF_THINGS, it's a pain to type). The only thing I don't like about D style is the suggested block comments:
Code: |
/*
* Some block
* comment.
*/
statement;
|
I've always disliked that syntax, I guess because I'm sort of a perfectionist and the comment block doesn't line up properly (*/ is one space away from the left edge and doesn't line up with the /* above it). I've always preferred:
Code: |
//==========...
// Some block
// comment.
//==========...
statement;
|
It just appears cleaner . I'd probably even volunteer to change all the Ares code, though I'm sure there are people against it (why do people dislike change so much?) |
|
Back to top |
|
|
larsivi Site Admin
Joined: 27 Mar 2004 Posts: 453 Location: Trondheim, Norway
|
Posted: Fri Oct 14, 2005 1:39 am Post subject: |
|
|
lgoss007 wrote: | Has a style been decided? Will the library use the D style guideline? I like it better than most guidelines (I dislike the WHOLE_UPPERCASING_OF_THINGS, it's a pain to type). The only thing I don't like about D style is the suggested block comments:
Code: |
/*
* Some block
* comment.
*/
statement;
|
I've always disliked that syntax, I guess because I'm sort of a perfectionist and the comment block doesn't line up properly (*/ is one space away from the left edge and doesn't line up with the /* above it). I've always preferred:
Code: |
//==========...
// Some block
// comment.
//==========...
statement;
|
It just appears cleaner . I'd probably even volunteer to change all the Ares code, though I'm sure there are people against it (why do people dislike change so much?) |
I'm sorry, but I find your "cleaner" version more noisy when reading the code. I personally find the other version much cleaner and easier to read. |
|
Back to top |
|
|
lgoss007
Joined: 13 Oct 2005 Posts: 20
|
Posted: Fri Oct 14, 2005 7:16 am Post subject: |
|
|
I'm sure you mean the:
make it more noisy. I just like that part because it seperates the code better, kind of like "This is a section". It's just much easier to recognize a section of code, especially if you only have a text editor with no syntax highlighting. However the "noise" can be removed:
Code: | //
// Some block
// comment
// |
Which is pretty similar, but it's flush with the left side. |
|
Back to top |
|
|
sean
Joined: 24 Jun 2004 Posts: 609 Location: Bay Area, CA
|
Posted: Fri Oct 14, 2005 9:26 am Post subject: |
|
|
Style guidelines will only apply to the code interface. While it would be nice to have the whole library look as if it were written by one person, everyone has different techniques so I am certain this is not possible The only comments where formatting matters as far as I'm concerned are the ones used to generate documentation. So long as everything else is clearly readable I don't care what you do. For what it's worth, the way I tend to write block comments in C+ is this:
Code: | ///////////////////////////////////////////////////////////////////////////////
// Blah blah blah
///////////////////////////////////////////////////////////////////////////////
|
I hadn't settled on a D style yet because I was waiting for a documentation generator I liked. I suspect I'll use DDoc style block comments in most cases now. |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|