 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / February 2006make not needed
Hello All, I notice the following: if I have A.java, B.java and C.java and if A calls B and C (directly or indirectly) it suffices to 'javac A.java' to get everything compiled as necessary, and so on. Please confirm that this is generally true and supply references; I have not been able to see this feature properly documented. Thanks in advance Ivan. > Hello All, I notice the following: if I have A.java, B.java and C.java and > if A calls B and C (directly or indirectly) it suffices to 'javac A.java' > to get everything compiled as necessary, and so on. > Please confirm that this is generally true and supply references; I have not > been able to see this feature properly documented. Thanks in advance > Ivan. This works for Sun's java compiler (not sure about others), but only holds true if the files are in the same directory (or maybe also for packages if they are in the correct directory relative to the current one), so some form of tool such as make is useful for any application larger than one package. > but only > holds true if the files are in the same directory No, they have to be in the source path. If no source path is set, the class path will be used to search not only for existing .class files, but also for source files. /Thomas  SignatureThe comp.lang.java.gui FAQ: ftp://ftp.cs.uu.nl/pub/NEWS.ANSWERS/computer-lang/java/gui/faq http://www.uni-giessen.de/faq/archiv/computer-lang.java.gui.faq/ > Hello All, I notice the following: if I have A.java, B.java and C.java and > if A calls B and C (directly or indirectly) it suffices to 'javac A.java' > to get everything compiled as necessary, and so on. > Please confirm that this is generally true and supply references; I have not > been able to see this feature properly documented. Thanks in advance > Ivan. Yes this is true. For those reasons you do not need Make. But what you do need is a build tool that can traverse all the directories specified and compile what has not been recursively compiled. A tool which can also create jars, wars, ears, run testing, installing and deployment create runtime information etc. In essence all the mundane tasks that is more than just compiling. For this, you need tools like Make, Ant or Maven. (search the net for something like "java build tools" to find lists of alternatives) I think the Java Language Spesification and/or the Java Virutal Machine Specification are the references to look at. mvh thomas > Hello All, I notice the following: if I have A.java, B.java and C.java and > if A calls B and C (directly or indirectly) it suffices to 'javac A.java' > to get everything compiled as necessary, and so on. If your compiler is set up correctly (source path or class path contain the source files). > Please confirm that this is generally true and supply references; What about the compiler documentation? http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/javac.html#searching But even without this feature, a build tool is still very handy. There is more than just compiling classes when you want to build an application or applet, like creating a jar, running native2ascii on resource bundles and properties files, etc. Also, it is convenient to automate javadoc production, running junit tests and other things. You can still do these things with make. I would stay away from ant, which is pure evil. /Thomas SignatureThe comp.lang.java.gui FAQ: ftp://ftp.cs.uu.nl/pub/NEWS.ANSWERS/computer-lang/java/gui/faq http://www.uni-giessen.de/faq/archiv/computer-lang.java.gui.faq/ >> Hello All, I notice the following: if I have A.java, B.java and C.java >> and [quoted text clipped - 9 lines] > > http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/javac.html#searching Hello Thomas et al, many thanks, especially for the above reference; this is just what I wanted though it's amazingly complicated. Ivan. > But even without this feature, a build tool is still very handy. There > is more than just compiling classes when you want to build an [quoted text clipped - 6 lines] > > /Thomas Thomas Weidenfeller skrev: > But even without this feature, a build tool is still very handy. I do not doubt that what I'm about to say is based on my lack of experience in this area, but I find the simplest way to gether all the build activities (run a source-code analyser, compile, jar, javadoc, etc.) is a DOS/shell script. I remember writing a DOS script in ten lines, and the equivalent ANT script was 100. The reason given to me why I shouldn't use a DOS-script at the time was that (apart from the flexibility that we weren't leveraging at the time), if I introduced any files that could not recursively be reached by javac (because of reflection, for example) then those files would not be compiled (by the javac commadn in the DOS script), but ANT would guarantee to find everything. And I'm sure that's true, but it's hardly a difficult bug (entire classes of functionality missing) to spot or correct, and I've always believed that solutions should save more work than the problems they solve. Though I must admit, that in work, our subsystems were quite well encapsulated, so we all usually built our own subsystems (with common jars) in isolation; maybe with a huge monolithic system, ANT etc. really shines. Hence my first sentence. .ed -- www.EdmundKirwan.com - Home of The Fractal Class Composition. Just for record, here's the .BAT file for compiling a servlet on my machine; there's no source-code analysing, jarring, etc., simply because I didn't want it. If I did I, would add the appropriate lines; it would still be a small script. Asceticism again. deltree /Y ..\..\util\jakarta-tomcat-5.0.16\webapps\ROOT\WEB-INF\classes\com\edmundkirwan\poker cls javac -d ..\..\util\jakarta-tomcat-5.0.16\webapps\ROOT\WEB-INF\classes -classpath servlet-2_3-fcs-classfiles -sourcepath src src\com\edmundkirwan\poker\start\PokerServlet.java javac -d ..\..\util\jakarta-tomcat-5.0.16\webapps\ROOT\WEB-INF\classes -classpath servlet-2_3-fcs-classfiles -sourcepath src src\com\edmundkirwan\poker\start\MessageBoardServlet.java > I do not doubt that what I'm about to say is based on my lack of > experience in this area, but I find the simplest way to gether all the > build activities (run a source-code analyser, compile, jar, javadoc, > etc.) is a DOS/shell script. I remember writing a DOS script in ten > lines, and the equivalent ANT script was 100. That's absolutely fine for many applications. Ant scripts certainly do blow out to be ridiculously hard to manage sometimes (which incidently is part of the reason Maven was conceived). The only downside to your approach is portability, but if your company always develops on particular platforms, this isn't going to cause any headaches (unless you change that platform). Tim > I do not doubt that what I'm about to say is based on my lack of > experience in this area, but I find the simplest way to gether all the > build activities (run a source-code analyser, compile, jar, javadoc, > etc.) is a DOS/shell script. I remember writing a DOS script in ten > lines, and the equivalent ANT script was 100. Ant is not a build tool, it is pure evil, spawn of hell. The advantage of a good build tool is dependency checking and triggering actions if certain things have changed. This provides - Less chance to forget something - Less time spent with doing unnecessary things. For example, I mentioned using native2ascii. One typically uses this tool to convert text files in a non-Latin 1 encoding to a format suitable for properties or resource bundle files. The following simple make rule would ensure that the tool is run when needed (when the input has changed), but not otherwise: someFile.properties: someFile.utf8 native2ascii -encoding UTF8 someFile.utf8 $@ Running native2ascii itself is not a big deal. But if, for example, the re-building of a jar depends on this file (defined in another make rule), then you better only create a new version of the properties file when the input has changed. > it's hardly a difficult bug (entire > classes of functionality missing) This entirely depends on the circumstances. If it is a class loaded via reflection, or the above mentioned properties file, you might not notice it. If you don't notice that you probably have an outdated version of a file while you maybe just prepare the master "tape out" for that big shipment of the product which is supposed to bring your company to the top, it is an entirely different thing. I have set up build systems for applications where at the end of a several hour build run (if everything was rebuild from scratch), the completely mastered CD-ROM image with the application, installer, documentation (also partly generated by the build system), OS patches and sample data was created. I at least wouldn't consider doing something like this without a build system. Not only to save time (thanks to dependency checking and a few other tricks a typical build just took minutes, not the full hours), but also all things which need to be done are done. These build systems were also used for our automatic nightly tests. The test system build a product with the build system, automatically installed it on a number of test systems and executed a bunch of automated tests. Oh, the test programs were of course also created with the build system. Build systems are kind of an insurance. Implementing and maintaining the build system is the premium you pay for this insurance. Like with a real insurance, you might never need the protection. Or you later figure out the coverage was incomplete (the build system didn't cover a particular dependency). Or the build system saved you. Some people like to gamble more than others. > Though I must admit, that in work, our subsystems were quite well > encapsulated, so we all usually built our own subsystems And what happens if the semantics of an API of a subsystem changes? A carefully set-up build system might detect that the application uses an outdated jar and starts the recompilation of that jar from the latest source. > maybe with a huge monolithic system, ANT etc. > really shines. Ant never shines. It's hot, but that's the hellfire inside. make is for sure not without problems (there is a vast collection of avid make haters out there on the Internet), but it is at least made for human usage. /Thomas SignatureThe comp.lang.java.gui FAQ: ftp://ftp.cs.uu.nl/pub/NEWS.ANSWERS/computer-lang/java/gui/faq http://www.uni-giessen.de/faq/archiv/computer-lang.java.gui.faq/ > (there is a vast collection of > avid make haters out there on the Internet) Anything which assigns different semantics to white space depending on the spelling of that white space is evil spawn of hell ... which of course includes the sig separator below as well as make. -- Tim Ward Brett Ward Limited - www.brettward.co.uk > Anything which assigns different semantics to white space depending on the > spelling of that white space is evil spawn of hell I was waiting for that comment about make. On one side we have make, which at a certain point insists on using a tab instead of single spaces. On the other side we have ant with XML. Which insists on proper nesting, proper closing of elements, a boatload of '<' and '>', a boatload of different elements with a boatload of different attributes in some deep nesting. Now, I rather know which side I prefer. I have no problems with putting up with an innocent tab. Actually, for may years it amazes me that people who are willing to put up with much worse things get mad about that tab character usage in make. It provides a nice and clean indentation as a side effect. It would probably have been better to use a different syntax there, but it really isn't a big thing to hit the tab key once in a while when writing a make file. /Thomas SignatureThe comp.lang.java.gui FAQ: ftp://ftp.cs.uu.nl/pub/NEWS.ANSWERS/computer-lang/java/gui/faq http://www.uni-giessen.de/faq/archiv/computer-lang.java.gui.faq/ > it > really isn't a big thing to hit the tab key once in a while when writing > a make file. I hit tab *keys* all the time when writing all sorts of things. This doesn't get tab *characters* inserted in the file, though. I suppose I could use a completely different editor differently configured just for make files ... but I find that I am able to earn a living without touching make files with a barge pole, so that's the option I choose. -- Tim Ward Brett Ward Limited - www.brettward.co.uk > I hit tab *keys* all the time when writing all sorts of things. This doesn't > get tab *characters* inserted in the file, though. I have heard that "reason" a thousand time. My answer is always the same: Your editor is broken. /Thomas SignatureThe comp.lang.java.gui FAQ: ftp://ftp.cs.uu.nl/pub/NEWS.ANSWERS/computer-lang/java/gui/faq http://www.uni-giessen.de/faq/archiv/computer-lang.java.gui.faq/ > > I hit tab *keys* all the time when writing all sorts of things. This doesn't > > get tab *characters* inserted in the file, though. > > I have heard that "reason" a thousand time. My answer is always the > same: Your editor is broken. Nope, it's carefully and deliberately configured exactly how I want it. In this configuration it is absolutely perfect at absolutely everything except make files. So I don't do make files, even when people want to pay me to - there are limits you know: it's a lifestyle choice - I'm sure you make them too. -- Tim Ward Brett Ward Limited - www.brettward.co.uk >> I hit tab *keys* all the time when writing all sorts of things. This >> doesn't >> get tab *characters* inserted in the file, though. > > I have heard that "reason" a thousand time. My answer is always the > same: Your editor is broken. My editor is fine, and it does the same. I specifically configure it to insert spaces when I hit the tab key, as do many other people. That's why so many editors have that option. > My editor is fine, and it does the same. I specifically configure it > to insert spaces when I hit the tab key, as do many other people. > That's why so many editors have that option. My editor normally inserts spaces when I press tab, but if I edit a Makefile it recognizes it as such, and inserts tab characters instead. It also warns me if a line is indented with spaces when it shouldn't be, and marks those spaces in a colour that stands out from the background. /gordon Signature[ do not email me copies of your followups ] g o r d o n + n e w s @ b a l d e r 1 3 . s e >>My editor is fine, and it does the same. I specifically configure it >>to insert spaces when I hit the tab key, as do many other people. [quoted text clipped - 5 lines] > be, and marks those spaces in a colour that stands out from the > background. I'm sure I *could* set up my editor to do the same, or, I could just use ant/maven, which has many other benefits, such as portability. For the amount of time I spend editing Makefiles, it doesn't seem worth it to figure out how to set it up like this. > I'm sure I *could* set up my editor to do the same, or, I could just > use ant/maven, which has many other benefits, such as portability. I'll go out on a limb here och suggest that Gnu Make likely runs on more platforms than Java does. > For the amount of time I spend editing Makefiles, it doesn't seem > worth it to figure out how to set it up like this. I don't spend a lot of time editing Makefiles either, but my editor recognizes them "out of the box". Setup time: 0. /gordon Signature[ do not email me copies of your followups ] g o r d o n + n e w s @ b a l d e r 1 3 . s e > I don't spend a lot of time editing Makefiles either, but my editor > recognizes them "out of the box". Setup time: 0. Which editor is that ? Since we seem to be in the middle of yet another Make-is-Good vs. Make-is-Bad -fest, let's up the ante and get into an editor war too ;-) (Only joking. But the question is genuine.) -- chris >> I don't spend a lot of time editing Makefiles either, but my editor >> recognizes them "out of the box". Setup time: 0. > > Which editor is that ? Emacs. /gordon Signature[ do not email me copies of your followups ] g o r d o n + n e w s @ b a l d e r 1 3 . s e >> I don't spend a lot of time editing Makefiles either, but my editor >> recognizes them "out of the box". Setup time: 0. [quoted text clipped - 7 lines] > > -- chris We've touched on spaces versus tabs too. Perhaps we should also move the Perl vs. Java discussion on to this thread? Dan. P.S. Should my opening curly braces be placed at the end of the line or on a line by themselves? SignatureDaniel Dyer http://www.dandyer.co.uk > P.S. Should my opening curly braces be placed at the end of the line or on > a line by themselves? Shhh...! The Elder Threads are not dead, they do but sleep. They shall awaken in the dark hour of Abion's greatest need, and when they arise their wrath shall be very terrible. -- chris >>I'm sure I *could* set up my editor to do the same, or, I could just >>use ant/maven, which has many other benefits, such as portability. > > I'll go out on a limb here och suggest that Gnu Make likely runs on > more platforms than Java does. I'd say you're right, but I'd say that Java runs on more systems that Gnu Make does. How do I specify that the build should tar and gzip a file and then copy it somewhere using Gnu Make for both windows and unix? > I don't spend a lot of time editing Makefiles either, but my editor > recognizes them "out of the box". Setup time: 0. So does mine... just checked it out. That still doesn't mean that using tab in a Makefile is not crap syntax. Make even gives you a warning when you use 8 spaces instead of a tab! >>> I hit tab *keys* all the time when writing all sorts of things. This >>> doesn't [quoted text clipped - 6 lines] > it to insert spaces when I hit the tab key, as do many other > people. That's why so many editors have that option. Just because you have broken it, rather than it being broken by design, doesn't mean it isn't broken. Besides, a proper editor would realize you were editing a Makefile and take action accordingly. SignatureNigel Wade, System Administrator, Space Plasma Physics Group, University of Leicester, Leicester, LE1 7RH, UK E-mail : nmw@ion.le.ac.uk Phone : +44 (0)116 2523548, Fax : +44 (0)116 2523555 >>>>I hit tab *keys* all the time when writing all sorts of things. This >>>>doesn't [quoted text clipped - 9 lines] > Just because you have broken it, rather than it being broken by design, doesn't > mean it isn't broken. It's far from broken. I like having spaces instead of tabs, and Make is the only unix tool I can recall using that treats tabs are special syntax separate from spaces. > Besides, a proper editor would realize you were editing a Makefile and take > action accordingly. Sure, but I can use the same argument against Make, and say that a proper build tool should be able to detect indenting etc, and take action accordingly. But it doesn't. >> Anything which assigns different semantics to white space depending on >> the [quoted text clipped - 10 lines] > Now, I rather know which side I prefer. I have no problems with putting > up with an innocent tab. I dont think there are any build tools for java out there that are close to perfect. I think a build tool that contains elements from both make and maven would be the best solution. I dont know about Ant, but I cant see it introducing anything of value than what Make/Maven already has. Here is a list of features a merged Make/Maven should have, IMHO... - Maven has a predefined directory structure so it can find the info/code where it expects it to be. - Mavens has an intelligent compile system, by only specifying the directories where source code is contained. - Maven has predefined maven modules which can perform a vast array of tasks, due to the directory structure. You dont have to script or program anything for most uses. - Maven automagically knows how to run tests, create jars, wars, perform deployment etc as long as the info it needs it located where it expects it. - Maven has one property file for the entire host:( it should be a property file for entire project. - Maven/Ant uses XML; NO USE OF XML should be allowed(XML is intended for machines, not for humans) - Make is too oriented around mundane details, This slows down the project because you have to reinvent the wheel for many of the same tasks for each new project. It also has some quirky syntax which should be removed. - Make is fast (native program), maven is slow (java program). Just performing a dead-end compilation in maven takes 2 seconds on a single file, in make its done in 0.1 second. - maven has a slow compilation cycle. For creating a jar it needs to perform seven or eight steps. When doing active developement, waiting for all those steps to complete can typically take 30-60 seconds. With make this can be done in 5-10 seconds (For this specific project). This is because, see next item... - Make allows one to control an action in detail, maven does not. I usually want an target called "compile" which performs all tasks of the jar target without running tests, this is for developement and a fast build turn-around. In maven this is not very possible. With make it is. - Maven requires a lot of network interaction to handle dependencies and to handle internal dependencies and deployment. This is handled efficiently and without any network interaction in make. So in essence maven works almost automagically, but with almost no ability to adapt to the project or users specific needs. While make gives you the adaptability, but at the cost of thousands of hours of make scripting for each new project. At the moment I dont know what I will be doing in the end, but I am seriously considering joining the maven project to do something about it. regards tom > I dont think there are any build tools for java out there that are close > to perfect. I think a build tool that contains elements from both make > and maven would be the best solution. I dont know about Ant, but I cant > see it introducing anything of value than what Make/Maven already has. Whatever happened to Ant 2? They were talking about it years ago but it seems to have disappeared off the radar. Dan. SignatureDaniel Dyer http://www.dandyer.co.uk On one hand you appear to have advanced experience: > I have set up build systems for applications where at the end of a > several hour build run (if everything was rebuild from scratch), the > completely mastered CD-ROM image with the application, installer, > documentation (also partly generated by the build system), OS patches > and sample data was created. On the other hand : > Ant never shines. It's hot, but that's the hellfire inside. I like ant. I like it better than make. I've made a handful ant make files and have been pleased. Much more so than most build systems made around make. Come to think of it I've only been happy with one make setup I've ever worked with. In my experience, admitadly no CD-ROMs getting burned, but releases, regression test, and documentaiton. For me ant has been excellent and superior to make. > If it is a class loaded via reflection Do you have any techniques for dependency tracking when reflection is used? Opalinski opalpa@gmail.com http://www.geocities.com/opalpaweb/ > I would stay away from ant, which is pure evil. Agreed. Too many people tends to think that Ant is a necessity for building Java software (like they tend to beleve that using an IDE is a necessity for doing Java development). I know many Java developers in many different organizations. The most effecient ones use gnumake (or variants) and emacs. In general they will suggest a development environment made of *powerful* but lightweight and independent tools. Some tend to think they need heavy tools in order to be *scalable*, while the exact opposite is actually the case. BTW: I think Eric Raymond wrote a book on the subject. >> I would stay away from ant, which is pure evil. > >Agreed. I would say ant is UGLY, not evil. To its credit, its scripts will run circles around anything you cook up with BAT files in terms of speed.. I used to do mine with a STOMP program that composed bat scripts for 4NT. It now generates ANT scripts. Further, the scripts run on all platforms. On the other paw it takes about ten times as much code to conditionally copy a file. For every I do anything in ant my first task is to find some time I or someone else has done it before to glean the magic incantations. It is limited to XML-like syntax which is very clumsy. see http://mindprod.com/jgloss/ant.html SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. >>>I would stay away from ant, which is pure evil. >> [quoted text clipped - 17 lines] > It is limited to XML-like syntax which is very clumsy. see > http://mindprod.com/jgloss/ant.html We use gnumake and ant on my project. Ant tends to be better for the java parts, and make for everything else. Make has simple targets to call ant. Platform independance is not an issue. > if A calls B and C (directly or indirectly) Indirectly including reflection? like so (not compiled): import java.util.ArrayList; public class A { public static void main(String args[]) throws Exception { ArrayList l = new ArrayList(); l.add( Class.forName("B")); l.add( Class.forName("C")); l.add( Class.forName(args[0])); } } Then no. Opalinski opalpa@gmail.com http://www.geocities.com/opalpaweb/ > > if A calls B and C (directly or indirectly) > [quoted text clipped - 15 lines] > opalpa@gmail.com > http://www.geocities.com/opalpaweb/ Theres no easy magic way. just 'javac A.java B.java C.java' or 'javac $(find . -name *.java)' Ant is good at allowing you to include and exclude files in the build, so you can enumerate them there easily too. Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.