Re: spam
proski Install a spam filter. I use SpamAssassin. You can download it from proski http://spamassassin.org/ Not everybody has the possibility to install a filter (i am not the system administrator) proski Please keep in mind that Automake developers don't have access to the proski mailing list administration. They use what they have. GNU cannot hire a proski full-time mailing list administrator. People in this list are software proski developers, not sysadmins, so it's not their guilt that the list is under proski spam attack. IMO it would help a lot, if only people were allowed to send messages to [EMAIL PROTECTED], who subscribed to the list. No full time administrator is needed, in fact it would be easy to implement. Regards, Christoph
spam
Hello, i am going to leave this list because it is not acceptable to receive hundrets of spam mails through [EMAIL PROTECTED] Bye, Christoph
Feature request: meta files wildcards (once again)
It is common style to generate c/cpp source files from some meta-languages. Examples are lex, yacc, QT's moc, swig, and probably many other tools. AFAIK there is currently no way to handle such files in automake and the recommended way is to write scripts editing Makefile.in's to add seperate rules for each file to be generated. This looks really unsatisfying to me because these scripts depend on current automake versions (see recently threads concerning KDE's am_edit script) and writing these scripts requires much effort. Though i have read some of the threads concerning wildcards in automake i once again suggest to integrate them into the automake stuff, because i believe that many developers would benefit from them. If i have a directory, which contains source files for exactly one executable / library, i do not want to list them redundantly in a Makefile.am (because i often forget to do so and the information is already there). I believe that most projeft structures are organised in that way and many people would like to list files using wildcards. Best Regards, Christoph
Antwort: Re: Feature request: meta files wildcards (once again)
alex I think the recommended way is to add suffix rules to produce the built alex sources, not edit the Makefile.ins. But is this really portable ? I looked at automake 1.4 info pages, and it tells something about GNU make: Handling new file extensions It is sometimes useful to introduce a new implicit rule to handle a file type that Automake does not know about. If this is done, you must notify GNU Make of the new suffixes. This can be done by putting a list of new suffixes in the `SUFFIXES' variable. For instance, currently Automake does not provide any Java support. If you wrote a macro to generate `.class' files from `.java' source files, you would also need to add these suffixes to the list: SUFFIXES = .java .class The actual documentation at http://sources.redhat.com/automake/automake.html#Suffixes does not mention GNU make anymore ... So i am a bit confused now. alex IMHO wildcarding is a separate issue, independent of whether sources are alex built or normal. Yes and no. Take the example of QT's moc files. They have to be generated from .h files, if the class defined in the .h file does mention a Q_OBJECT macro. I would love to have something in my Makefiles which greps for the string Q_OBJECT in all .h files this directory contains. For each file where this is found, the moc has to be started. I think this is not possible at the current time without writing a script which edits the Makefile.in's (this is what KDE Developers do). Besides many developers want to use wildcarding as well even if they do or do not use meta files. Regards, Christoph
Re: Feature request: meta files wildcards (once again)
alex Could you check if the automake 1.6.x docs make the same reference to alex GNU make instead of just make when talking about suffix rules? No, they don't. So this is enough if you have a special file type from which source files should be generated. But the moc problem isn't solved (correct me if i am wrong). Thank you, Christoph
Re: building/installing Python modules?
skip For example, if I have this chain of dependencies: skip skip build/lib.linux-i686-2.3/array.so skip skipdepends on skip skip build/temp.linux-i686-2.3/arraymodule.o skip skipwhich depends on skip skip Modules/arraymodule.c skip skip (the locations of the .o and .so files are determined by distutils) and then skip diddle some bits in arraymodule.c, neither .../arraymodule.o nor skip /array.so get rebuilt the next time I run make. For the person skip installing one time from source this isn't a significant problem, but can be skip a nightmare for a developer, especially if something more global changes skip like Includes/object.h... On my system (linux 2.4, python 2.1.1), the dependency stuff works well. In fact in the above situation, one single 'python setup.py install' command would be enough. But i agree, that the build support of distutils is limited to small extension modules (if you want to mix extension modules with binary applications or build an application with embedded python, the distutils support fails). However, for a python developer it has much less effort to use distutils, because one does only has to learn _one_ language (python) instead of 3 or 4 for the auto* stuff.
Re: BTW: This is not the last problem
Adriaan KDE has a lot of extra meta-files that need to be generated: moc files Adriaan for Qt, kidl files (and from them _skel.cpp and _stub.h) for DCOP, and Adriaan _signal.h files for DCOPSignals. These are typically not explicitly listed Adriaan in the Makefile.am. Instead, we write This seems to be a real problem of automake and is also related to the wildcard discussion. In a normal makefile, one single rule would be enough to handle meta files like the qt moc files, but in automake it is a pity to write a perl script with 100's of lines to edit the Makefile.in's just to give rules for generating each single moc file from it's corresponding h file. Maybe it would be useful to handle meta files in automake (i think this is already done for lex and yacc, maybe it is possible to handle meta files more generally). Regards, Christoph
Re: building/installing Python modules?
skip Sure, if all you want to distribute is a few extension modules. What about skip if you want to distribute the library they wrap as well? That's where the skip auto*/libtool gang comes in (I hope - it's difficult enough for me to figure skip out how this works that I'm still pondering the benefits). Distutils won't skip help there, and in that case, by eliminating setup.py I would be eliminating skip yet another configuration file format people have to know about. (Forget skip that it happens to be Python code. You still have to know what calls to skip make.) OK, i agree with that. I thought of using the auto* tools for building python extensions a few months ago now, but since i was using swig, i did not know how to integrate the swig meta files (*_wrap.c) into the auto* stuff - the way to write a script which edits the Makefile.in does not look practical to me. Now i have a patchwork, using GNU make (to generate the meta files) together with distutils (build / install the extensions). Very unsatisfying. Christoph
Re: BTW: This is not the last problem
Adriaan KDE has a lot of extra meta-files that need to be generated: moc files Adriaan for Qt, kidl files (and from them _skel.cpp and _stub.h) for DCOP, and Adriaan _signal.h files for DCOPSignals. These are typically not explicitly listed Adriaan in the Makefile.am. Instead, we write This seems to be a real problem of automake and is also related to the wildcard discussion. In a normal makefile, one single rule would be enough to handle meta files like the qt moc files, but in automake it is a pity to write a perl script with 100's of lines to edit the Makefile.in's just to give rules for generating each single moc file from it's corresponding h file. Maybe it would be useful to handle meta files in automake (i think this is already done for lex and yacc, maybe it is possible to handle meta files more generally). Regards, Christoph
Re: building/installing Python modules?
Why don't you use the distutils module coming with python ? They provide a platform-independent building/installing mechanism of Python modules and c-extensions. Regards, Christoph
