Thank you for your reply, as you can see, I have another file structure and I like it, because: I like when the "root" of the project contains all GNU files like README, AUTHORS, etc., configure.ac, root Makefile.am The src subdirectory contains only source code of the application and people can check it out and edit in their favourite IDE and commit changes without having to be affraid that they will mess up some files they don't understand. I have Makefiles in lib directory (because I like the concept that applications are composed of library and its frontend) and bin directory, where the compiled frontend statically linked with the "library" is going to appear. And I usually have a datadir and a docdir with their Makefile.am files. And also a m4 directory and build-aux directory since I really want things to be separate. If I run ./configure from the "root", I got the output in the respective directories along with object files. (you can take a look to the file structure here: http://stereozoom2.svn.sourceforge.net/viewvc/stereozoom2/stereozoom2/trunk/ ) I think that there should be some hints like what directory structures are smart in the autoconf manual or somwhere else... Do you think that this layout is smart? But I don't really understand the "build tree" and "source tree" concept yet. Could you give an example? Do you see something else wrong with my approach apart from the fact that it (probably) can't support VPATH builds? Don't you think that having things separate is also very good, when people come to your project and they know where is what without knowing anything about autotools? Regarding top posting: I am really sorry if I do something wrong, but I thought that last time, I have just quoted somebody. Could anyone explain to me what is not good? I thought that even readers of archived mailing lists could appreciate quoting. Thank you, Matej _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
