-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have to admit, I have never gained a good sense of how to use the gnu Autotools, though I've spent far more time trying than I have with Ant. TrollTech's qmake, OTOH, is very easy to learn. It may simply be the case that Ant hasn't attempted the more complex things Autotools address. I can see some things in Ant which if not addressed soon will lead to the same kinds of obscurity I find in the Autotools. One of the problems I had with Autotools is that the Cygwin install I used had two different versions installed, and I was reading man pages from one version while working with another. /That/ is not a reflection on the difficulty of using Autotools. Nonetheless, when I do look at the documentation, I find myself following references to other documents which are not consistent with the reffering document. KDevelop will generate the files I need for this task, and thus far, I've been able to use the generated results without a problem. However, when I try to understand what all of it means, I am at a loss. Is there a problem brewing with this system? When one script generates another, which generates yet another, it seems there is a potential for the result to become incomprehensible even to the creators of the tools. Does anybody share my concern? STH -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFAQWNFwX61+IL0QsMRAi+HAKCSbJ1qUSd7XB9+f/dHAoK5t1vwfQCcDTg7 UYxEAlpymyIgr1eVT930Svw= =9N51 -----END PGP SIGNATURE-----
Yes, using GNU auto tools may be confusing for ant user. With ant, only one file (build.xml) is needed. With auto tools, there are actually two steps: one is wether you need "configure" script, and the other one is the "Makefile" script. To generate "configure", you'll need to manually create configure.in and use autoconf, whereas for "Makefile", you'll need to create Makefile.am and use automake. Check out this book: http://sources.redhat.com/autobook It uses older auto tools, but the concept is still the same. Regards, Verdi
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday 28 February 2004 11:56 pm, Cincai Patron wrote:
Yes, using GNU auto tools may be confusing for ant user. With ant, only one file (build.xml) is needed.
I found autotools confusing before I ever looked at a build.xml. The book I was looking at when I gave up on trying was: http://sources.redhat.com/autobook I'll check again, but the last time I tried to use the examples, they were simply wrong. Looking in the documentation for the tools did little to clarify what was wrong with them.
With auto tools, there are actually two steps: one is wether you need "configure" script, and the other one is the "Makefile" script.
To generate "configure", you'll need to manually create configure.in and use autoconf, whereas for "Makefile", you'll need to create Makefile.am and use automake.
Then there's the issue of config.h. I believe all open source C/C++ software should build by untarring the source and typing ./configure && make && make install. Any options should be, well, optional. That is ./configure --help should only be necessary if I want to change the default /usr/local/app-name - --prefix, etc. Ant has its ideosyncrasies, but, from my experience, Ant has the advantage that I was able to make it work for me, whereas, I have yet to be very successful with Autotools. As I say, I'll try again. I'm not sure where autogen and pkg-config fit into this picture. There are also libtool and libtoolize as well as autoheader, autoscan, autoupdate, etc. Then there's Makefile.am verses Makefile.ac. Or is that configure.am verses configure.ac?
Check out this book: http://sources.redhat.com/autobook It uses older auto tools, but the concept is still the same. I might start here: http://inti.sourceforge.net/tutorial/libinti/autotoolsproject.html
Regards, Verdi
I'm really not trying to be difficult, or to find fault for the sake of it. I'm just a bit frustrated with the time it's taking me to become productive in C++ compared to what I can already do in Java. STH -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFAQYQAwX61+IL0QsMRAqNpAJ9qeBkjCeiXZQtaNtIv4SooQ9neNACfRiRS xQAd4R1pWJAOP3UJ5f9dxv0= =ZX/4 -----END PGP SIGNATURE-----
"Steven T. Hatton" <hattons@globalsymmetry.com> [29 Feb 2004 01:17:29]:
Then there's the issue of config.h.
What's the issue here? config.h is created automatically by running configure.
I'm not sure where autogen and pkg-config fit into this picture.
I've never had to deal with autogen, so I can't say anything about it. pkg-config comes from the gnome project and allows you to get configuration data about installed programs, like needed libraries or compiler flags. pkg-config is often used in configure scripts to check for availability of a given library/package and to add its linker and compiler options to the makefile(s).
also libtool and libtoolize
Libtools is used to ease the creation of shared libraries across different Unix flavors. libtoolize is the tool to add libtool to your project, just like gettextize adds gettext support.
as well as autoheader
Automatically creates config.h.in, the template that is then used by configure to create config.h.
autoscan, autoupdate, etc.
Simply read 'info autoconf' and search for these terms That should explain it.
Then there's Makefile.am verses Makefile.ac. Or is that configure.am verses configure.ac?
You're heavily mixing these up :) Makefile.am is the Makefile fragment you create. automake then turns this into a full-blown Makefile.in, which in turn is then used by configure to finally create Makefile by replacing place holders by their actual values as determined during the configure run. configure.in and configure.ac are actually two names for the same thing, the configure template you write and which gets turned into the configure script by running autoconf. configure.ac is the nowadays preferred name, as it makes clearer that this is a file meant for autoconf. Philipp
Steven T. Hatton wrote: Autotools documentation is really not that good, but when you get it, well, you get it. The most common way you use it (in this order) is as follows: input program output acinclude.m4/configure.ac aclocal aclocal.m4 configure.ac autoheader config.h.in Makefile.am automake -a Makefile.in Makefile.in/config.h.in/aclocal.m4 ./configure Makefile Another great feature of autotools is the sanity checks. Once you have a Makefile, you don't need worry anymore (most of the time). If you modify configure.ac, just type make and it goes through all process needed to generate the new Makefile for you. The ./configure script has several advantages compared to custom makefiles. I usually set a lot of flags when developing. to optimize: CXXFLAGS="-O2 -fomit-frame-pointer -DNDEBUG" ./configure --prefix=/usr to debug overflows LDFLAGS="-lefence" ./configure --prefix=/usr and so on. []s Davi
I have to admit, I have never gained a good sense of how to use the gnu Autotools, though I've spent far more time trying than I have with Ant. TrollTech's qmake, OTOH, is very easy to learn. It may simply be the case that Ant hasn't attempted the more complex things Autotools address. I can see some things in Ant which if not addressed soon will lead to the same kinds of obscurity I find in the Autotools.
However, when I try to understand what all of it means, I am at a loss. Is there a problem brewing with this system? When one script generates another, which generates yet another, it seems there is a potential for the result to become incomprehensible even to the creators of the tools. Does anybody share my concern?
STH
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 01 March 2004 06:28 pm, Davi de Castro Reis wrote:
Steven T. Hatton wrote:
Autotools documentation is really not that good, but when you get it, well, you get it. Do you happen to know a way to dump all the targets in a Makefile in a way similar to Ant's -p (or older -projecthelp)?
Don't get me wrong. I'm not at a complete loss as to what's going on. I've been able to go into the files in things such as festival and make significant changes to the way they build. http://www.cstr.ed.ac.uk/projects/festival/. It's just that I don't have the recipe down.
The most common way you use it (in this order) is as follows:
input program output acinclude.m4/configure.ac aclocal aclocal.m4 configure.ac autoheader config.h.in Makefile.am automake -a Makefile.in Makefile.in/config.h.in/aclocal.m4 ./configure Makefile
I've been off doing other things, and haven't been able to revisit this issue. I really do want to get the hang of starting from scratch, but right now, I can continue to work at a higher level, and use tools to generate these things. I really don't like to use tools like these to do things for me unless I understand what they are doing for me. But I also like to make progress.
Another great feature of autotools is the sanity checks. Once you have a Makefile, you don't need worry anymore (most of the time). If you modify configure.ac, just type make and it goes through all process needed to generate the new Makefile for you.
I do believe there is a right way to do all this, and a lot of people don't do it correctly. Not that I know how to do it correctly, but I know what correct results look like. A good example is Xerces-C. It requires more than a simple ./configure to get it going. It's well documented, so I can't criticize too much. Nonetheless I have to wonder if it's that way simply because no one has taken the time (away form other productive efforts) to figure out how to get it right.
The ./configure script has several advantages compared to custom makefiles. I usually set a lot of flags when developing. to optimize: CXXFLAGS="-O2 -fomit-frame-pointer -DNDEBUG" ./configure --prefix=/usr to debug overflows LDFLAGS="-lefence" ./configure --prefix=/usr and so on.
Oh, I've been using this stuff from the consumming end for the better part of a decade. I know it does great things. Ant does some pretty nice stuff as well. I don't recall where, but I do recall one leading developer proclaim that after working with Ant she'd be happy if she never had to look at a Makefile again. Of course Ant is typically used for Java builds which do not target specific hardware platforms. It's bound to be less complicated. I suspect there are ways to create the Autotools files so they are much more coherent than they often turn out in real life. It doesn't help to be on an unfamiliar platform reading a tutorial from one version, documentation from another, and actually invoking a third version of the tools when trying to learn. I was on my father's WinDOS 98 using cygwin. One other thing I'm not sure about is how to work the Qt moc stuff into a standard Autotools system.
[]s Davi
STH -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFAQu9uwX61+IL0QsMRAixNAKCCLFlRQUdWj6qAKSV0w7CwbK1kLACfac62 WBkmm9cAKQdr7RLqLRjY+Ys= =foSt -----END PGP SIGNATURE-----
Steven T. Hatton wrote:
Of course Ant is typically used for Java builds which do not target specific hardware platforms. It's bound to be less complicated. I suspect there are ways to create the Autotools files so they are much more coherent than they often turn out in real life.
It doesn't help to be on an unfamiliar platform reading a tutorial from one version, documentation from another, and actually invoking a third version of the tools when trying to learn. I was on my father's WinDOS 98 using cygwin.
One other thing I'm not sure about is how to work the Qt moc stuff into a standard Autotools system.
If you want to learn how to use autotools that quickly, you might buy a copy of Vaughan, Elliston, Tromey and Taylor: GNU Autoconf, automake, and libtool. There's an online version on http://www.newriders.com/ (IIRC) but there's no substitute for the real thing and you'd be donating to GNU just by buying it. Also, it contains chapters on m4 and cross-compiling that I just know you want to know about. Compiling Qt with moc and autotools can be done, but is a little harder. I don't know if you can get tmake (or qmake) to work with autotools, but you can compile Qt without it by putting the right rules in a standard makefile (or Makefile.am, which is much, much easier). Yes. Autotools is harder than you might want. But it is very reliable. I can write code on linux and just know that it will work on solaris. You might want also to look at the gcj project on http://www.gnu.org/ It will compile java to source so that it might run as fast as C++. Maybe even some day C++ will be obsolete. I've been told that java already has templates designed in so that a java version of STL-like stuff is possible, and clearly there's a good reason for reserving the keyword const. Just add a fully working gcj and java is at least as good as C++, maybe even better: somehow I always feel that STL just isn't quite as elegant as how you'd do things in Python or even APL. -- JDL Non enim propter gloriam, diuicias aut honores pugnamus set propter libertatem solummodo quam Nemo bonus nisi simul cum vita amittit.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 01 March 2004 03:58 pm, John Lamb wrote:
Steven T. Hatton wrote:
One other thing I'm not sure about is how to work the Qt moc stuff into a standard Autotools system.
If you want to learn how to use autotools that quickly, you might buy a copy of Vaughan, Elliston, Tromey and Taylor: GNU Autoconf, automake, and libtool. There's an online version on http://www.newriders.com/ (IIRC) but there's no substitute for the real thing and you'd be donating to GNU just by buying it. Also, it contains chapters on m4 and cross-compiling that I just know you want to know about.
I think for now, I just need to find out who to go from start to `make install'. Every approach I've see seems drastically different. The documentation for each tool is like the professor who thinks every student in his class is going into his profession. That is, the docs tend to ignore the automatic means of performing the documented steps provided by the other Autotools.
Compiling Qt with moc and autotools can be done, but is a little harder. I don't know if you can get tmake (or qmake) to work with autotools, but you can compile Qt without it by putting the right rules in a standard makefile (or Makefile.am, which is much, much easier).
I know it's possible. I do it with some of my own projects. But it's all automated by KDevelop, so I don't know how it works. I can look to find out, when I find the time.
Yes. Autotools is harder than you might want. But it is very reliable. I can write code on linux and just know that it will work on solaris.
Same can be said for Ant. People really need to be willing to reexamine their tools continually to find better and simpler ways of doing things.
You might want also to look at the gcj project on http://www.gnu.org/ It will compile java to source so that it might run as fast as C++. Maybe even some day C++ will be obsolete. I've been told that java already has templates designed in so that a java version of STL-like stuff is possible, and clearly there's a good reason for reserving the keyword const.
I'm still not sure if templates will add all that much to Java. I've found that in most cases where templates would be useful, I can usually isolate the type casting to very limited and regular points in the program. Type casting is about the only thing templates seem to eliminate as far as I can see. The negatives of templates seem to outway the positives as far as I can tell. Sure, it takes some getting used to in Java, but once you accept things are as they are, and are willing to work with them, it works quite well.
Just add a fully working gcj and java is at least as good as C++, maybe even better: somehow I always feel that STL just isn't quite as elegant as how you'd do things in Python or even APL.
Java is not always that slow. I don't know what benchmarks have been recorded for Java 3D and OpenGL, but Java3D is pretty snappy. The slow part of Java typically involves the time it takes to load into memory. I kind of like being able to download the same jar on any operating system, and run it without a problem. I suspect native compiles will always be able to get a bit of an edge over byte compilers simply because the JVM isn't typically natively compiled on each system where it's used. I'm sure I have yet to find the hidden gems in C++. I suspect there is a lot to like about it once you master it. But there is this from the author of _Mastering C++_: http://www.horstmann.com/cpp/pitfalls.html This isn't directed at you, but I have the sense the C++ world suffers from a certain amount of arrogant complacency which isn't justified by the current environment. Sun is now back to focusing a lot of effort on an area where Java should have been far more successful but for that lack of interest. http://wwws.sun.com/software/javadesktopsystem/index.html But this is comical to a veteran KDE user: "With the Sun Java Desktop System, Sun has delivered the first viable Microsoft Windows alternative. The Java Desktop System is a more affordable, secure desktop that is designed to thrive in a Windows-centric world." BTW, the Trolls get it. They know the objective is to make it easy to use.
JDL
Non enim propter gloriam, diuicias aut honores pugnamus set propter libertatem solummodo quam Nemo bonus nisi simul cum vita amittit.
Do I have to get out my Langenscheidt Latin? :-) STH -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFAQ7FpwX61+IL0QsMRAjQFAKC9Kx2kYHQZ1q/HBM6ZLn5CLIy93wCgo2m5 jjdU0rytrSVMlj6/HvUAr1s= =tzG+ -----END PGP SIGNATURE-----
Steven T. Hatton wrote:
I think for now, I just need to find out who to go from start to `make install'.
Here goes: you've got a file hello.cc that you want to compile: Create Makefile.am: == ## Process this file with automake to produce Makefile.in ## bin means install in binaries directory ## PROGRAMS means identify this as a program (as opposed HEADER, DATA, library) bin_PROGRAMS = hello ## hello is the prefix you created on the last line ## SOURCES is the list of files required to compile it hello_SOURCES = hello.cc == That's easy enough and almost clear. You'll also need a configure.ac. The quick way is to run autoscan and then mv configure.scan to configure.ac. You'll also need to add automake support with the AM_INIT_AUTOMAKE macro. You end up with: == # -*- Autoconf -*- # Process this file with autoconf to produce a configure script. AC_PREREQ(2.57) AC_INIT(hello,0.1,email@address) AC_CONFIG_SRCDIR([hello.cc]) AC_CONFIG_HEADER([config.h]) AM_INIT_AUTOMAKE # Checks for programs. AC_PROG_CXX # Checks for libraries. # Checks for header files. # Checks for typedefs, structures, and compiler characteristics. # Checks for library functions. AC_CONFIG_FILES([Makefile]) AC_OUTPUT == Now a few extras # touch NEWS README AUTHORS ChangeLog creates some files the GNU build expects for automake to work. You'll also need some standard incantations: # aclocal # autoheader # automake -a # autoconf Just so you don't keep repeating these, write a script 'bootstrap': == #! /bin/sh aclocal \ && autoheader \ && automake --gnu --add-missing \ && autoconf == Then if things don't do what you want, just do # ./bootsrap and they will. Now look and you'll see you have a configure script. Run it: # ./configure A makefile appears 'as if by magic' # make and presto: your file is compiled and will run _in situ_. The real work of autotools is usually sorting out libraries, but find out first how it compiles a simple program, then move on. Libraries cause the real problem because they may have to go in specific locations. Hence the --prefix= option, which, by the way, you've already got. Also, shared libraries are harder than static ones, but necessary for some C++ development, but autools will handle all the complexity for you with a little help from libtoolize.
I'm still not sure if templates will add all that much to Java. I've found that in most cases where templates would be useful, I can usually isolate the type casting to very limited and regular points in the program. Type casting is about the only thing templates seem to eliminate as far as I can see. The negatives of templates seem to outway the positives as far as I can tell. Sure, it takes some getting used to in Java, but once you accept things are as they are, and are willing to work with them, it works quite well.
Simple template functions aren't _that_ useful, but STL stuff is. For example, the STL code to sum all the elements of a dynamically resizeable vector of doubles is reasonably simple: double total = 0; for( std::vector<double>::iterator i = my_vector.begin(); i != my_vector.end(); ++i ) total += *i; Java has some support for this kind of thing, but not yet quite as good. The thing I don't like is the clunkyness of the code. Python is nicer. APL could do it as my_data?+/my_vector (IIRC)
Java is not always that slow. I don't know what benchmarks have been recorded for Java 3D and OpenGL, but Java3D is pretty snappy. The slow part of Java typically involves the time it takes to load into memory.
Depending on the estimate C++ can run 5-15 times as fast, though for many GUI apps that's not an issue. The last java app I wrote deliberately slows itself down so you can see it work. What gcj may do is make java compete with C++ on speed also.
Non enim propter gloriam, diuicias aut honores pugnamus set propter libertatem solummodo quam Nemo bonus nisi simul cum vita amittit.
Try pasting the text into Gooogle. -- JDL Non enim propter gloriam, diuicias aut honores pugnamus set propter libertatem solummodo quam Nemo bonus nisi simul cum vita amittit.
John Lamb <J.D.Lamb@btinternet.com> [Tue, 02 Mar 2004 18:32:29 +0000]:
Now a few extras # touch NEWS README AUTHORS ChangeLog creates some files the GNU build expects for automake to work. You'll
Not if tell automake that this is foreign, i.e. not a GNU project.
also need some standard incantations: # aclocal # autoheader # automake -a # autoconf
Since you're requiring 2.57, you can just as well simply call autoreconf --force --install which also has that added benefit that it will recurse through subdirs.
Sure, it takes some getting used to in Java, but once you accept things are as they are, and are willing to work with them, it works quite well.
And Java will get generics with the next version, i.e. templates for Java :) Philipp
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 02 March 2004 01:32 pm, John Lamb wrote:
Steven T. Hatton wrote:
I'm still not sure if templates will add all that much to Java. I've found that in most cases where templates would be useful, I can usually isolate the type casting to very limited and regular points in the program. Type casting is about the only thing templates seem to eliminate as far as I can see. The negatives of templates seem to outway the positives as far as I can tell. Sure, it takes some getting used to in Java, but once you accept things are as they are, and are willing to work with them, it works quite well.
Simple template functions aren't _that_ useful, but STL stuff is. For example, the STL code to sum all the elements of a dynamically resizeable vector of doubles is reasonably simple:
double total = 0; for( std::vector<double>::iterator i = my_vector.begin(); i != my_vector.end(); ++i ) total += *i;
I never write loops without the {}, except for demonstration purposes. It's too easy to overlook when maintaining code. I guess it's a matter of taste. I found templates to have some hidden costs, such as bloated autogenerated code. They are also a bit tricky when it comes to recursion which is something I am very inclined to use. As I said, the only thing they seem to add to a language is the obviation of type casting. Type casting is not nearly as problematic in Java as in C++, so getting around it doesn't gain us that much. The ability to use the ++ operator comes from operator overloading, not from templates, so templates, in themselves won't get rid of the Iterator.hasNext() and Iterator.next() in the following code: /** Main */ import java.util.ArrayList; import java.util.Iterator; public class Main { public Main() { } public static void main(String[] args) { /* Create the dynamic data array; Java doesn't handle dynamic arrays of primitive types, so we use wrappers. Java does, however, support more flexible creation of fixed size arrays at runtime. */ ArrayList myData = new ArrayList(); for(int i = 0; i < 11; i++){ myData.add(new Double(i)); } double result = 0; /* The Java way: Iterator is common to most Java container types. Enumeration is available in "legacy" types. Note that we have to cast from Object to Double in order to access the Double.doubleValue() method; */ Iterator it = myData.iterator(); while(it.hasNext()){ result += ((Double)it.next()).doubleValue(); } System.out.println("result="+result); /* A C'ish approach. */ result = 0; for(int i = 0; i < myData.size(); i++){ result += ((Double)myData.get(i)).doubleValue(); } System.out.println("result="+result); /* A C++'ish approach. */ result = 0; for(Iterator itr = myData.iterator(); itr.hasNext(); result += ((Double)it.next()).doubleValue()); System.out.println("result="+result); /* If you like using the [] style indices for arrays. */ result = 0; Double[] da = (Double[])myData.toArray(new Double[0]); for(int i = 0; i < da.length; i++){ result += da[i].doubleValue(); } System.out.println("result="+result); } } /*end Main*/
Java has some support for this kind of thing, but not yet quite as good. The thing I don't like is the clunkyness of the code. Python is nicer. APL could do it as my_data?+/my_vector (IIRC)
Mathematica: Plus @@ myData
Java is not always that slow. I don't know what benchmarks have been recorded for Java 3D and OpenGL, but Java3D is pretty snappy. The slow part of Java typically involves the time it takes to load into memory.
Depending on the estimate C++ can run 5-15 times as fast,
I have a genuine mistrust of benchmarks, but I would like to know what sources you have on this. The general philosophy of Java is to write code that is intelligible before even thinking about efficiency. That is not the case with Java3D. In Java3D members are shamelessly exposed as public, and many of the common approaches to passing values are avoided for the sake of efficiency.
though for many GUI apps that's not an issue. The last java app I wrote deliberately slows itself down so you can see it work. What gcj may do is make java compete with C++ on speed also.
Non enim propter gloriam, diuicias aut honores pugnamus set propter libertatem solummodo quam Nemo bonus nisi simul cum vita amittit.
Try pasting the text into Gooogle.
-- JDL
I did, but didn't get any hits. When I take a break, I'll try again. - -- STH Nil Conscire Sibi. Tandem Si. http://baldur.globalsymmetry.com/gs-home/images/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFARoPpwX61+IL0QsMRAnhfAKDG29PgqPLnQld3C/bgJjHxdfzV5QCgmtyz yXeqjbU507ARKMxqGbYxpNs= =PbEy -----END PGP SIGNATURE-----
Steven T. Hatton wrote:
Depending on the estimate C++ can run 5-15 times as fast,
I have a genuine mistrust of benchmarks, but I would like to know what sources you have on this. The general philosophy of Java is to write code that is intelligible before even thinking about efficiency.
I don't recall offhand because I agree that bencharks are not that important. I found one packing algorithm I wrote in both java and C++ took about 5 times as long in java than in C++ compiled withouth optimisations. For a more extreme comparison, try big matrix multiplication and compile the C++ code -O3 -mfpmath=sse -msse -msse2 -maling-double. But, as you suggest, speed is usually not the issue. Robust and quick development is. That's where I think java wins. I'm hopeful that what gcj will do is allow java to run at similar speeds to C++ and FORTRAN. Of course that won't convince all C++ programmers to change. I still get FORTRAN programmers ask me why I use C++ (they still think it's much slower) - and they can't even recurse! -- JDL Non enim propter gloriam, diuicias aut honores pugnamus set propter libertatem solummodo quam Nemo bonus nisi simul cum vita amittit.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 04 March 2004 02:54 am, John Lamb wrote:
I don't recall offhand because I agree that bencharks are not that important. I found one packing algorithm I wrote in both java and C++ took about 5 times as long in java than in C++ compiled withouth optimisations. For a more extreme comparison, try big matrix multiplication and compile the C++ code -O3 -mfpmath=sse -msse -msse2 -maling-double.
But is that innate to the language and the differences between byte compiling and assembling, or is it simply that C++ has libraries, and compiler features which support this kind of thing? Again, I have to refer to Java3D. I'm not sure how the javax.vectormath package would stand up, but it would be a likely place to look for optimized math algorithms. http://java.sun.com/products/java-media/3D/forDevelopers/J3D_1_3_API/j3dapi/... A thing to consider is that once the instructions are loaded in memory, the byte code interpretation issues are irrelevant. It's just a question of the algorithms being used, and the way the VM was compiled. If it's written in C++, guess what? :-) There are also ways to use .so's with Java. My guess is, such areas of optimization can be isolated in most cases. If so, and if they are going to be used by many different programs, or in many different parts of a large project, they could be written in C++. Bear in mind that the compiler you get from www.javasoft.com is just a reference implementation. There are other VM's such as IBM's.
But, as you suggest, speed is usually not the issue. Robust and quick development is. That's where I think java wins. I'm hopeful that what gcj will do is allow java to run at similar speeds to C++ and FORTRAN.
Part of the problem with C++ is simply the lack of good supporing tools. I'll say this again. KDevelop is the best thing going for C++ open source. http://www.kdevelop.org/graphics/pic_corner/3.0/full_ide.png
Of course that won't convince all C++ programmers to change. I still get FORTRAN programmers ask me why I use C++ (they still think it's much slower) - and they can't even recurse!
If I understand correctly, gcc converts all the source code it compiles into a generic transcode(?) before assembling. I'm wondering how much the particular language used to create the source will matter, if that's the case. I'm certainly not out to kill C++. I believe it's good to have alternative languages. Java took a great deal from C++. The C++ community could learn a lot by examining why Java is so attractive to programmers. What are the meanings of these these expressions? const char* bears[3] = {"Papa", "Mama", "Baby"}; char* const bears[3] = {"Papa", "Mama", "Baby"}; // I find this bizarre! const char* const bears[3] = {"Papa", "Mama", "Baby"}; See: Ellis & Stroustrup, pp 133-134
JDL
STH -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFARx0EwX61+IL0QsMRAtiQAKCYh/ZA/po7O4WWU32iYj3tr8E4GQCgr00b nRoOvC8355rMyp5BuUFjwPA= =l9dS -----END PGP SIGNATURE-----
Steven T. Hatton wrote:
But is that innate to the language and the differences between byte compiling and assembling, or is it simply that C++ has libraries, and compiler features which support this kind of thing? Again, I have to refer to Java3D. I'm not sure how the javax.vectormath package would stand up, but it would be a likely place to look for optimized math algorithms.
Not innate. A CPU that was designed specifically to run java bytecode would probably run java at about the same speed as anything else compiled. I believe such a CPU has been suggested but not built. The best optimized math algorithms are probably still written in FORTRAN, though that's a very specific problem and these libraries are very carefully crafted. -- JDL Non enim propter gloriam, diuicias aut honores pugnamus set propter libertatem solummodo quam Nemo bonus nisi simul cum vita amittit.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 04 March 2004 12:11 pm, John Lamb wrote:
Steven T. Hatton wrote:
But is that innate to the language and the differences between byte compiling and assembling, or is it simply that C++ has libraries, and compiler features which support this kind of thing? Again, I have to refer to Java3D. I'm not sure how the javax.vectormath package would stand up, but it would be a likely place to look for optimized math algorithms.
Not innate. A CPU that was designed specifically to run java bytecode would probably run java at about the same speed as anything else compiled. I believe such a CPU has been suggested but not built.
The best optimized math algorithms are probably still written in FORTRAN, though that's a very specific problem and these libraries are very carefully crafted.
I'll give a simple example of why I don't accept that argument. A few years back I wrote some code to produce 3 random floats. I thought I had written to code correctly, it kept coming back with the same value for all three. Well, as it turns out, random isn't really random. It's a seeded algorithm designed to simulate floats. It generates subsequent values based on the system clock. The code was executing so fast it all happened in the same clock cycle. The CPU runs faster than the system clock, as you probably knew. As a related example, there are Java encryption implementations which directly access libraries written in C. Once the code's in memory, it doesn't matter how it got there, interpreted, bytecompiled, assembled, or entered with thumb switched counters. The instruction pointer increments from one instruction to the next, and loads instruction into the instruction register(s), prefetching, piplining, and all considered. As an example, Mathematica is an interpreted language with very limited capability to "compile". Compiling basically means bytecompiling, as I understand it. (It's just hyper-Lisp). Some calculations are extremely fast.
-- JDL
STH -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFASCJFwX61+IL0QsMRAkRnAKCPqUnYH7RAv7ZfrSeJKiMbk9asmwCgv/Qe 4VMcSIcNsyAaQwDnpU1jofI= =pbaC -----END PGP SIGNATURE-----
John Lamb wrote:
Steven T. Hatton wrote:
Depending on the estimate C++ can run 5-15 times as fast,
I have a genuine mistrust of benchmarks, but I would like to know what sources you have on this. The general philosophy of Java is to write code that is intelligible before even thinking about efficiency.
I don't recall offhand because I agree that bencharks are not that important. I found one packing algorithm I wrote in both java and C++ took about 5 times as long in java than in C++ compiled withouth optimisations. For a more extreme comparison, try big matrix multiplication and compile the C++ code -O3 -mfpmath=sse -msse -msse2 -maling-double.
But, as you suggest, speed is usually not the issue. Robust and quick development is. That's where I think java wins. I'm hopeful that what gcj will do is allow java to run at similar speeds to C++ and FORTRAN.
Of course that won't convince all C++ programmers to change. I still get FORTRAN programmers ask me why I use C++ (they still think it's much slower) - and they can't even recurse!
-- JDL
Non enim propter gloriam, diuicias aut honores pugnamus set propter libertatem solummodo quam Nemo bonus nisi simul cum vita amittit.
-- To unsubscribe, email: suse-programming-e-unsubscribe@suse.com For additional commands, email: suse-programming-e-help@suse.com Archives can be found at: http://lists.suse.com/archive/suse-programming-e
C/C++ is 25-50% slower than FORTRAN in (heavy floating point) benchmarks I have run over the last 15 years on everything from CRAY X-MP's down to modern P4 based systems, especially with commercial compilers (Convex, SGI, Intel & PGI), & double especially comparing gcc to commercial F77/F90. If your work needs that last iota of speed, there is no substitute for F77, warts & all.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 02 March 2004 01:32 pm, John Lamb wrote:
Steven T. Hatton wrote:
I think for now, I just need to find out [how] to go from start to `make install'.
Here goes: you've got a file hello.cc that you want to compile: Create Makefile.am: This is another point of consternation for me. I see a lot of C++ source with the .cpp extension. It's not a big deal, but it does complicate things such as file type filtering, etc. And most C++ source I've seen comes with headers in *.h files. I tend to favor .hpp, since the .h is used in C as well as C++. I looked in the gcc-3.2.3/libstdc++-v3/src/ and .cc is the winner. They don't have any header files, so I can't judge by that.
== ## Process this file with automake to produce Makefile.in
Oh, and the bloody ## is some kind of magic comment, no? ...
== # -*- Autoconf -*-
Do I smell Emacs?
# aclocal # autoheader # automake -a # autoconf Just so you don't keep repeating these, write a script 'bootstrap': == #! /bin/sh
aclocal \ && autoheader \ && automake --gnu --add-missing \ && autoconf == Then if things don't do what you want, just do # ./bootsrap and they will.
Thanks. That looks quite usefull. I need to try what Phillipp suggested as well.
The real work of autotools is usually sorting out libraries, but find out first how it compiles a simple program, then move on. Libraries cause the real problem because they may have to go in specific locations. Hence the --prefix= option, which, by the way, you've already got. I tend to approach that in the opposite direction. I put things where I want them, and use /etc/ld.so.conf or LD_LIBRARY_PATH to find them. I shoot myself in the foot every once in a while, but I find it easier than to risk someone else overwriting my .so's if they're in the 'standard' location. It also saves having to su to do installs.
Also, shared libraries are harder than static ones, but necessary for some C++ development, but autools will handle all the complexity for you with a little help from libtoolize.
I actually made that work once for a toy project.
JDL
STH -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFARpafwX61+IL0QsMRAkDUAKDM8hoE7owLPgOdZV9kIvZ70CxYyACfVPjm /JSL74vOSMWrJoLcBLIFWEg= =brkK -----END PGP SIGNATURE-----
Steven T. Hatton wrote:
This is another point of consternation for me. I see a lot of C++ source with the .cpp extension. It's not a big deal, but it does complicate things such as file type filtering, etc. And most C++ source I've seen comes with headers in *.h files. I tend to favor .hpp, since the .h is used in C as well as C++. I looked in the gcc-3.2.3/libstdc++-v3/src/ and .cc is the winner. They don't have any header files, so I can't judge by that.
Shouldn't be a problem with autotools. The rules for handling .cpp are the same as those for .cc and there are header files don't get compiled directly.
== ## Process this file with automake to produce Makefile.in
Oh, and the bloody ## is some kind of magic comment, no? ...
No magic, just a comment. Automake comments IIRC always use two hashes.
# -*- Autoconf -*- Do I smell Emacs?
No. This comes from autoscan output. Autotools works just fine without emacs installed. Come to think of it, I probably don't have emacs installed.
Thanks. That looks quite usefull. I need to try what Phillipp suggested as well.
Philipp's is the easier version. It's only necessary to write your own if you do something nonstandard. -- JDL Non enim propter gloriam, diuicias aut honores pugnamus set propter libertatem solummodo quam Nemo bonus nisi simul cum vita amittit.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 02 March 2004 01:32 pm, John Lamb wrote:
Now a few extras # touch NEWS README AUTHORS ChangeLog
I thought there was a way of importing templates for these files. No?
-- JDL
Non enim propter gloriam, diuicias aut honores pugnamus set propter libertatem solummodo quam Nemo bonus nisi simul cum vita amittit.
Tacitus? STH -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFAUhnxwX61+IL0QsMRAtDQAKCcIfcasHJlTH24iQcH1XDFqIz11ACg0wC5 X7ndtkjXH5WGbLiCF/uU0SI= =gWhW -----END PGP SIGNATURE-----
Steven T. Hatton wrote:
# touch NEWS README AUTHORS ChangeLog I thought there was a way of importing templates for these files. No?
IIRC automake -a or automake --add-missing copies templates from some automake source directory. I think Phillip or someone posted something about this earlier.
Non enim propter gloriam, diuicias aut honores pugnamus set propter libertatem solummodo quam Nemo bonus nisi simul cum vita amittit.
Tacitus?
Bernard de Linton (probably) -- JDL Non enim propter gloriam, diuicias aut honores pugnamus set propter libertatem solummodo quam Nemo bonus nisi simul cum vita amittit.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 12 March 2004 03:48 pm, John Lamb wrote:
Steven T. Hatton wrote:
# touch NEWS README AUTHORS ChangeLog
I thought there was a way of importing templates for these files. No?
IIRC automake -a or automake --add-missing copies templates from some automake source directory. I think Phillip or someone posted something about this earlier.
Unless I did something out of order, that didn't pull those particular files. I thought it would. Beats me?
Bernard de Linton (probably) ?? -- JDL
STH -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFAUik3wX61+IL0QsMRAhVlAJ0dPQS1bel6WdIt0Q/V3gEcKHTezgCgo0MG 2GRhdQW4vceD/TjzobPSJho= =D5oA -----END PGP SIGNATURE-----
Steven T. Hatton wrote:
# touch NEWS README AUTHORS ChangeLog
I thought there was a way of importing templates for these files. No?
Probably there is. Maybe Automake only adds the stuff actually in /usr/share/automake-* In fact, these four can be empty. There is a standard format for ChangeLog - just look at some standard package to see it. The others don't have any particular format as far as I know. So, if you can't find a more definitive answer, # touch NEWS README AUTHORS ChangeLog will work. -- JDL Non enim propter gloriam, diuicias aut honores pugnamus set propter libertatem solummodo quam Nemo bonus nisi simul cum vita amittit.
Steven T. Hatton wrote:
On Friday 12 March 2004 03:48 pm, John Lamb wrote:
Steven T. Hatton wrote:
# touch NEWS README AUTHORS ChangeLog
I thought there was a way of importing templates for these files. No?
IIRC automake -a or automake --add-missing copies templates from some automake source directory. I think Phillip or someone posted something about this earlier.
Unless I did something out of order, that didn't pull those particular files. I thought it would. Beats me?
These files are not created by automake. Just touch them. If you use cvs, look for the cvs2cl.pl script. It is a very nice and simple tool to create ChangeLog files from cvs log. []s Davi
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday 14 March 2004 03:11 pm, Davi de Castro Reis wrote:
These files are not created by automake. Just touch them. If you use cvs, look for the cvs2cl.pl script. It is a very nice and simple tool to create ChangeLog files from cvs log.
Thanks for the tip. My next objective is to get subversions up. I have a CVS server set up. I've been informed subversions is easier to work with than traditional CVS.
[]s Davi
Back in ancient times there were standard templates for these files. I feel certain of that. I believe John may be on to someting regarding the files which are copied. I seem to recall something along those lines. BTW, I guess I would be incorrect to assume any of the autotools sniff for new source files and automatically add them? STH -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFAUlwWwX61+IL0QsMRAgG8AJwNnr9ky6vV+uG/UD9QdghshGtEzgCgxNot cIJVtkRgwqnkVlm9lby2lqQ= =pZL5 -----END PGP SIGNATURE-----
Steven T. Hatton wrote:
These files are not created by automake. Just touch them. If you use cvs, look for the cvs2cl.pl script. It is a very nice and simple tool to create ChangeLog files from cvs log.
Thanks for the tip.
Nice. I didn't know of such a thing.
BTW, I guess I would be incorrect to assume any of the autotools sniff for new source files and automatically add them?
Correct. You have to add the source files to the appropriate Makefile.am. Fortunately, that usually means little more than adding your file to the end of the *_SOURCES list in Makefile.am and running make. If Makefile.am has changed, make will rerun enough autotools stuff to (usually) detect the sources you added. -- JDL Non enim propter gloriam, diuicias aut honores pugnamus set propter libertatem solummodo quam Nemo bonus nisi simul cum vita amittit.
Hiya: I am running SuSE v9 pro on my laptop & I would like to install it on a external USB 60 gig drive, and set up apache. I am having the worse time trying to install on an external drive and was hoping you all could offer some words of wisdom in my direction about the best way /least painful way to approach this. The windows/hardware people at this company tell me to GHOST a copy/image and then configure Apache. once installed. TIA Siobhan
On Sunday 14 March 2004 10:06, Suzanne McSweeney-DesRochers wrote:
Hiya: I am running SuSE v9 pro on my laptop & I would like to install it on a external USB 60 gig drive, and set up apache. I am having the worse time trying to install on an external drive and was hoping you all could offer some words of wisdom in my direction about the best way /least painful way to approach this.
It should be relatively painless to get SuSe installed. That said, you need to patch and recompile the kernel before you will be able to boot with the usb drive as your root. Contact me off list if you would like a patch file. I have one for 2.4.21 and one for 2.6.3. You will also have to have all the correct usb modules in the initrd file. And last but not least, this is the wrong forum for this question the list you want for this type question is suse-linux-e. Coy
"Steven T. Hatton" <hattons@globalsymmetry.com> [1 Mar 2004 03:08]:
Do you happen to know a way to dump all the targets in a Makefile in a way similar to Ant's -p (or older -projecthelp)?
Make -np But that prints out *all* rules and targets, including the ones built into make. Philipp
Steven T. Hatton wrote:
On Monday 01 March 2004 06:28 pm, Davi de Castro Reis wrote:
Steven T. Hatton wrote:
Autotools documentation is really not that good, but when you get it, well, you get it.
Do you happen to know a way to dump all the targets in a Makefile in a way similar to Ant's -p (or older -projecthelp)?
You can try bash-completion, although not all the targets will be as usefull as you think.
Oh, I've been using this stuff from the consumming end for the better part of a decade. I know it does great things. Ant does some pretty nice stuff as well. I don't recall where, but I do recall one leading developer proclaim that after working with Ant she'd be happy if she never had to look at a Makefile again.
Well, since I learned how to work with autotools I never looked at a Makefile again.
Of course Ant is typically used for Java builds which do not target specific hardware platforms. It's bound to be less complicated. I suspect there are ways to create the Autotools files so they are much more coherent than they often turn out in real life.
I agree with you. But autotools is very old and very portable. There is no "let us rewrite from scratch" option. I really think that m4 was a bad choice. But you simply can't throw all the macros already written and tested in a huge amount of platforms. Ant is simpler, but the Java platform is also much more well-behaved.
One other thing I'm not sure about is how to work the Qt moc stuff into a standard Autotools system.
Take a look at how kdevelop do it. []s Davi
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 02 March 2004 06:06 pm, Davi de Castro Reis wrote:
Steven T. Hatton wrote:
Do you happen to know a way to dump all the targets in a Makefile in a way similar to Ant's -p (or older -projecthelp)?
You can try bash-completion, although not all the targets will be as usefull as you think.
I'm not sure I follow. Bash completion is something I think of doing on the command line.
Well, since I learned how to work with autotools I never looked at a Makefile again.
I still believe the underlying script should be intelligible. Scripting is typically an exercise in global variable reference and non-returning branch statements (GOTO). That's why people created strongly typed, structured programming languages, because the other way stinks.
Of course Ant is typically used for Java builds which do not target specific hardware platforms. It's bound to be less complicated. I suspect there are ways to create the Autotools files so they are much more coherent than they often turn out in real life.
I agree with you. But autotools is very old and very portable. There is no "let us rewrite from scratch" option. I really think that m4 was a bad choice. But you simply can't throw all the macros already written and tested in a huge amount of platforms. Ant is simpler, but the Java platform is also much more well-behaved.
It's not impossible that some, if not all, of that could be automatically translated into a different form. It might even be possible to programmatically identify linear dependence between different macros, and eliminate the redundant parts.
One other thing I'm not sure about is how to work the Qt moc stuff into a standard Autotools system.
Take a look at how kdevelop do it.
Sure. After I get this other stuff figured out. :-) Here's my list of commands that I have encountered working with autotools. It is by no means exhaustive, nor overly exclusive. It's just what seems relevant to learn when focusing on this topic: tools aclocal ar as autoconf autoheader automake autoreconf autoscan autoupdate configure doxygen imake install m4 make nm And a list of files in the root of a KDevelop project, significantly pruned: Files AUTHORS COPYING ChangeLog Doxyfile Doxyfile.am INSTALL Makefile.am Makefile.cvs Makefile.in NEWS README TODO acinclude.m4 aclocal.m4 autom4te.cache config.h.in configure.in configure.in.bot configure.in.in stamp-h.in
[]s Davi
Note that there is no mention of cvs other than the Makefile.cvs. No mention of ssh, ssh-keygen, ldconfig, /etc/ld.so.config, yacc/bison, sed, awk/gawk, and so on and so forth. STH -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFARDPhwX61+IL0QsMRAlkYAKC6jmY0USk4mc8JaTkqYXJGf3n5PACgzco7 ji++mayoSF+PU9mlREVuVzI= =/vKG -----END PGP SIGNATURE-----
On Saturday 28 February 2004 07:57 pm, Steven T. Hatton wrote:
I have to admit, I have never gained a good sense of how to use the gnu Autotools, though I've spent far more time trying than I have with Ant. TrollTech's qmake, OTOH, is very easy to learn. It may simply be the case that Ant hasn't attempted the more complex things Autotools address. I can see some things in Ant which if not addressed soon will lead to the same kinds of obscurity I find in the Autotools.
Autotools are worthless and add excessive complexity and undocumented (or maybe ill documented) crap to your source tree. If all you want is a good makefile, then I would recommend taking a look at makepp project. Syntax is similar to make but much easier since you do not have to take care of the dependencies yourself. Salman
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 01 March 2004 07:21 pm, Salman Khilji wrote:
Autotools are worthless and add excessive complexity and undocumented (or maybe ill documented) crap to your source tree.
If all you want is a good makefile, then I would recommend taking a look at makepp project.
Syntax is similar to make but much easier since you do not have to take care of the dependencies yourself.
Salman
I haven't used it on big projects, but for my smaller tutorrial level projects, qmake has served me quite well. Part of the reason I want to learn the Autotools system is simply because it is used in almost all GNU C/C++ projects. STH -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFAQ7KZwX61+IL0QsMRAtx9AKCZaei+MbQWNaiNR02dwPv1F0AnYwCeMW+0 oNJLuCiS6dzTyzNNPYIUA6g= =U/S6 -----END PGP SIGNATURE-----
Salman Khilji <skhilji@tampabay.rr.com> [1 Mar 2004 16:21:21 -0800]:
Autotools are worthless and add excessive complexity and undocumented (or maybe ill documented) crap to your source tree.
That may be your view. My experience with dealing with quite a few software packages over the 10 years I'm dealing with Linux tells me that the autotools are the only sane way if you want to have your source code more or less adapt to different environments and give users the chance to easily modify defaults. Yes, parts are undocumented or at least not well documented, but you can learn the basics in a few hours. Writing good makefiles also isn't exactly easy, does that keep you from writing them? Philipp
participants (9)
-
Cincai Patron -
Coy Krill -
Davi de Castro Reis -
John Lamb -
Philipp Thomas -
Salman Khilji -
Steven T. Hatton -
Suzanne McSweeney-DesRochers -
William A. Mahaffey III