news about the Qt integration?
Hi Ralf, Have you managed to look into my patches about the Qt MOC integration? Thanks, Gergely
Re: news about the Qt integration?
Hello Gergely, * Gergely Risko wrote on Sun, Nov 01, 2009 at 07:36:08PM CET: Have you managed to look into my patches about the Qt MOC integration? No; and I'm really sorry about that. I hope to have some more Automake time next weekend though. My next Automake work items are the zsh testsuite fixes, OBJCXX, then your QT patch series. Cheers, Ralf
Re: news about the Qt integration?
On Sun, 1 Nov 2009 20:11:07 +0100, Ralf Wildenhues ralf.wildenh...@gmx.de writes: My next Automake work items are the zsh testsuite fixes, OBJCXX, then your QT patch series. Thank you, and do not feel hurried by me, I was just asking. The paperwork is still pending in the company of mine anyway, but let's hope it gets solved as soon as possible. Cheers, Gergely
Re: QT Plugins, target build order AND BUILT_SOURCES
Hello Andre, Your example is pretty complex, and doesn't make the problem obvious. Merely adding libCustomPlugin.la to BUILT_SOURCES doesn't seem to introduce a cycle in the build dependencies, at least from a 'make -n' in an example package that has this Makefile.am but no other files. It may help to see a reduced example package that still has the cycle. Cheers, Ralf
Re: OS independent build results
Hello Andreas,
* Andreas Otto wrote on Sun, Oct 25, 2009 at 07:20:16PM CET:
currently I try to improve my build environment. I want to add OS
independent build results like
java class files or mono clr libraries/excutable
into the distribution
1) the problem is the VPATH build. the files from above are
in the srcdir and not in the builddir (1'st location)
If the tools needing them are from you, you can peek at how automake-
generated rules deal with files that can be in both trees, by trying
first the build dir file and then falling back on prepending $(srcdir)/.
If you need a compiler or other tool to find files, either you may be
able to pass some flags like -I$(srcdir) or so, or you copy (or symlink;
you can use $(LN_S) to have the latter but fall back to the former; see
'info Autoconf --index LN_S' for more info).
Yet another possibility is to just update all files in the source tree:
as long as a shipping tarball won't ever change for a user building from
the tarball, and the generated files are not system-dependent, that
should work.
2) if one of the prerequisite file are touched
(java - *.java, mono - *.cs)
the new class or clr file(s) are in the builddir (2'nd location)
after the build
- now I have 2 locations from which the dist or a other command
like the java jar can take the files
3) only for case 2) the VPATH build have to clean up the files
Recent Automake has an internal variable CONFIG_CLEAN_VPATH_FILES.
Files listed in this variable are removed only if $(srcdir) != ..
If this would help you, we can try to make a public API for this
variable.
4) for a very special vase VB.NET CLR files can only be compiled
on a special OS (Windows). A non-Windows OS should use
the dist files and print a WARNING message if a build have to be
done
You can turn on system-dependent parts of a makefile with conditionals,
see 'info Automake Conditionals'. You can extend installation with
install-{data,exec}-{local,hook}, see 'info Automake Extending'.
one solution would be that vor a VPATH build I can specify a set
of dirs/files (in a variable) to COPIED first from the srcdir
into the builddir, these copied files have to be removed in a
distclean - attention the copy have only be done if the
target of the same name is not available
You can loop over files and use 'test -f' on the target file.
If you have problems with a specific rule, please show the code you
have.
HTH. Cheers,
Ralf
Re: OS independent build results
Hi, this is my solution: this add a new target .vpath_hook to the build environment and this target copy the files/directories listed in VPATH_FILES from the src into the build environment. the copy is necessary because tools like JAR expect the files in the build directory. .vpath_hook is the FIRST target in BUILT_SOURCES to garantee that the copy is done before any furter action are done. 1. acinclude.m4 # # SC_SET_VPATH_HOOK -- # # add support for VPATH build # # Arguments: # none # need variable VPATH_FILES be defined # # Results: # # Add a new variable VPATH_HOOK/CLEANUP/DIST to automake # # AC_DEFUN([SC_SET_VPATH_HOOK], [ AC_MSG_CHECKING([add VPATH hook]) AC_SUBST([VPATH_HOOK], ['@if test ! -f .vpath_files -a $(srcdir) != . ; then (cd $(srcdir) cp -r $(VPATH_FILES) $(abs_builddir);) touch .vpath_files chmod -R u+w $(VPATH_FILES) echo VPATH copy; else true; fi touch .vpath_hook']) AC_SUBST([VPATH_HOOK_CLEANUP], ['-rm -f .vpath_hook; test -f .vpath_files rm -fr .vpath_files $(VPATH_FILES)']) AC_SUBST([VPATH_HOOK_DIST], ['-rm -f $(distdir)/.vpath_hook']) ]) 2. example java Automake.am: ... # ## VPATH setup .vpath_hook: $(VPATH_HOOK) VPATH_FILES = javamsgque javamsgque_MqS.h javamsgque_MqBufferS.h javamsgque_MqS_WAIT.h javamsgque.jar BUILT_SOURCES = .vpath_hook $(mqs_DATA) javamsgque_MqS.h javamsgque_MqBufferS.h MAINTAINERCLEANFILES = $(BUILT_SOURCES) javamsgque_MqS_WAIT.h javamsgque/*.class ... distclean-local: $(VPATH_HOOK_CLEANUP) dist-hook: $(MQS_MAIN) $(VPATH_HOOK_DIST) mkdir $(distdir)/javamsgque chmod u+w $(distdir)/javamsgque cp javamsgque/*.class $(distdir)/javamsgque chmod u+w $(distdir)/javamsgque/*.class !important! is that make clean should not clean the *.class files. I use the MAINTAINERCLEANFILES to clean this files also
Re: OS independent build results
* Andreas Otto wrote on Sun, Nov 01, 2009 at 12:17:05PM CET: this add a new target .vpath_hook to the build environment and this target copy the files/directories listed in VPATH_FILES from the src into the build environment. the copy is necessary because tools like JAR expect the files in the build directory. .vpath_hook is the FIRST target in BUILT_SOURCES to garantee that the copy is done before any furter action are done. Note that parallel make (make -jN) does not guarantee that .vpath_hook is completed before the other BUILT_SOURCES are updated. Not sure if you need that, but if you do, you could make the former a prerequisite of the latter ones. Cheers, Ralf
is anyone using threaded automake?
Since the 1.11 release I have not seen one bug report about $AUTOMAKE_JOBS aka. automake running several Perl threads to update several Makefile.in files concurrently, for speed. If you have more than a couple of Makefile.am files and a SMP system, then it should help. Is anyone using it? Has anyone seen issues with it? Bugs could manifest in unstable Makefile.in content, i.e., running it a second time creates a different file, and/or unstable warning/error output from automake, thus by definition be hard to detect and hard to debug. Which is why I'm asking whether I should assume it just works or nobody uses it or there is not enough use to expose bugs. Thanks, Ralf
Re: is anyone using threaded automake?
Hi Jason, * Jason Sewall wrote on Sun, Nov 01, 2009 at 06:28:31PM CET: On Sun, Nov 1, 2009 at 6:45 AM, Ralf Wildenhues wrote: Is anyone using it? Has anyone seen issues with it? I didn't even know it existed, but I just tried it out and it seems to generate correct output for a project I have with 12 Makefile.am files. I have a quad core machine and set AUTOMAKE_JOBS=4. The performance gains are fairly small, however: $ AUTOMAKE_JOBS=1 time automake 1.31user 0.19system 0:01.51elapsed 100%CPU $ AUTOMAKE_JOBS=4 time automake 1.62user 0.24system 0:01.14elapsed 163%CPU Yeah, the perl thread spawning really has high overhead, and the output synchronization isn't all that performant either. I did get quite acceptable speedup out of a 150-makefile project. And they are imperceptible with autoreconf. Oh well. Thanks for testing, Ralf
