Referee 1 ******************************************* This paper discusses Netbuild, which is a tool that can automate the processing of installing and configuring software libraries. Netbuild works on heterogeneous platforms. The paper describes the basic architecture of Netbuild and the initial implementation. As a software tool, Netbuild would be a welcome and useful addition to the application programmers toolbox. Programmers spend an inordinate amount of time searching for and installing software libraries. Such searches and installations are often met with frustration as most such libraries do not install, nor are correctly configured in an easy manner. If Netbuild could overcome such frustration, it would be a truly useful software tool. Details in the paper are "light". The outline that is presented of Netbuild seems reasonable. One thing I couldn't quite figure out if there were any language dependent issues? Will Netbuild work for C++ software libraries that extensively use templates? What about mixed language software libraries, will Netbuild install and configure different languages equally as well? Because the paper discusses an "initial implementation", it is difficult to assess Netbuild's effectiveness. It would be great if the authors could update the project to include any initial results. Referee 2 ******************************************* E: Referee Comments (For Author and Editor) ------------------ Claims in the paper like "In General the more libraries on which a program depends,t he fewer environment it can run on" are largely unsubstantiated though understandable. There is no data given substantiating such claims. E.g. I ran in to problems where a program consisted on a large number of libraries 10 and it was more portable that a program that was only dependent on one library. The point I believe one needs to make is that portability statements must be derived from the libraries. In Section C. Describe more about the efforts that are underway. Also the section implies that Net build is not stable, which would be bad for this journal issue. Section Searching for local libraries It is not clear who one deals with dependencies in dynamically linked libraries. assume I compile a dependent on b with X and b is compiled with Z that is incompatible with X can that be done? The attributes introduced in section "Identifying target ..." imply that a weight must be imposed on this attributes, probably to build a weighted sum. No analysis is provided on what would be best, if this is a good idea, or whay and whay not certain attributes are chosen. The use of cgi and a global database may not be such a good idea, as it causes a lot of delay. Why not define a service-based on other more advanced technologies. later in the paper this is displayed as a good part, but it seems to me this is more a "hack" than real motivation. What short comings does the tar format have, no explanation is given. Section NetCompile: How can I express the dependencies of the application for a particular target platform. General statements are made, but they are not substantiated with an example or a better explanation. Section Distribution ... How can one prevent malicious libraries, wouldn’t every library need to be signed? Section Related Work A more precise description of what you want to "borrow" is in order. Section Status ... we would like to see a discussion about the various data models. Unfortunately, this is not described here. Apply the technology to at least one other code example not just Netsolve F: Presentation Changes all over: During the print the following errors were obvious a , is followed always by the next letter and a blank e.g. Internet,a nd instead of "Internet, and" Section D. A diagram necessary to explain architecture/usage. Section 3. paragraph NetBuildTool. This whole paragraph needs rewriting. The explenation of shims could be better Section 3. General It is not clear if the information is stored in a global directory or not. Section "Authenticaticity ..." Do not use a colloquial phrase such as the sentence with "okay" in it this is not very precise language for an academic paper. Suggestion: Nevertheless, I believe this work is still relevant, but unfortunately not ready by itself for a journal publication. There is a very nice paper describing the contributions of Netsolve to the Grid community. Maybe this work can be summarized in one page and added to that paper? Referee 3 ******************************************* Referee Comments (For Author and Editor) NetBuild builds on the successful repertoire of tools that have been developed at the University of Tennessee. It automates many of the tedious details that are involved in remote access of software libraries. However, the presentation makes it clear that NetBuild is little more than an IMakefile system that is grid-aware. Some of the goals of this project (e.g., "automate the process of selecting ... software libraries over the Internet", "automate the construction of such libraries") are quite lofty. But the superficial manner in which these topics are "solved" (by NetBuild) indicate that the researchers have a very incomplete understanding of the issues involved. For instance, selection of appropriate software is not merely a matter of tagging libraries with architectural parameters and selecting them. John Rice and colleagues at Purdue have been trying to design such automatic algorithm selection systems for the past 20 years, and the problem is one of the most open issues in numerical computing. Please see the work by this group for more holistic approaches to this problem. The section on "matching" assumes that ready-made lookup tables are available to aid in this activity. There is no mention of how software performance is to be assessed and how the set of attributes is used to distinguish "good" performance from "bad." What are the decision algorithms to be used? How sophisticated can they get? It may be the case that the authors want to merely "facilitate access" once the methodological details of the software selection are resolved. If this is the case, then NetBuild is really just a bunch of glue scripts that will form part of a larger, high-level, problem-oriented, application-specific system. I have heard Jack Dongarra speak about a vision of "adaptive software libraries" but will be quite surprised if this simplistic solution is what he had in mind. There are also a lot of assumptions about how computations are conducted on the grid. What if algorithms have to be switched dynamically during a computation? What are the checkpointing facilities? Access to libraries cannot simply be a matter of running them remotely. In conclusion, I recommend that the authors address more serious issues and attempt to incorporate NetBuild in a larger context of dynamic software selection, compilation, and linking technologies.