http://blog.gmane.org/gmane.comp.lib.boost.build hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.lib.boost.build/19836 Or, to fit within the (`foobar`) shell invocation, optionally turn fully stripped lines into a "list of strings" result. Rene Rivera 2008-12-02T02:05:10 http://permalink.gmane.org/gmane.comp.lib.boost.build/19835 Indeed. But best you can do is complain to Sourceforge and hopefully they will eventually provide more sensible choices (there are no choices for EOL designations on portable archives). Especially if many, many, many users complain. Rene Rivera 2008-12-02T01:59:54 http://permalink.gmane.org/gmane.comp.lib.boost.build/19834 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build Oliver Zheng 2008-12-01T21:48:46 http://permalink.gmane.org/gmane.comp.lib.boost.build/19833 The attached has already been sent to spirit-devel< at >lists.sourceforge.net; however, it's probably more appropriate to this list. Could someone on this list provide pointers on how to modify the Jamfile to actually run the examples (in particular, the mini_xml1.cpp) with the input file specified? _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build Larry Evans 2008-12-01T20:00:32 http://permalink.gmane.org/gmane.comp.lib.boost.build/19832 Hi Daniel, As it happens, this 'date' command actually prints a trailing newline. I'm afraid you get to strip newline. E.g.: ECHO "X:" ; local x = [ SHELL "date +%s" ] ; ECHO $(x) ; ECHO "Y:" ; local y = [ MATCH "(.*)[\n]" : $(x) ] ; ECHO $(y) ; ECHO "end" ; produces the following output for me: X: 1228161017 Y: 1228161017 end Note that you need Boost.Jam 3.1.17 for this. In prior version, things get a bit trickier: nl = " "; ECHO "X:" ; local x = [ SHELL "date +%s" ] ; ECHO $(x) ; ECHO "Y:" ; local y = [ MATCH "(.*)[$(nl)]" : $(x) ] ; ECHO $(y) ; ECHO "end" ; Let me know if this helps. Maybe, we should modify 'SHELL' to (optionally) strip the last trailing whitspace? - Volodya _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build Vladimir Prus 2008-12-01T19:52:41 http://permalink.gmane.org/gmane.comp.lib.boost.build/19831 I have successfully gotten my jam file to work to an acceptable level. (My Jam file is listed below.) My lib target now declares a dependency on a file called "Parliament.jar", and I have replaced the notfile target with a make target for this file. The make target's action invokes an ant script, which compiles a bunch of Java sources, archives them into the file Parliament.jar, and then invokes the javah tool to generate the JNI header files that are included by the lib target's sources. This has a few anomalies, which I can live with, at least for now: (1) If any of the Java sources change, then all of the lib sources are rebuilt, even though only a few of them depend on the JNI headers. This is because I am using the jar file as a proxy for the actual JNI headers in the dependencies. Ideally, the jar file would be an internal detail of the ant script that the jam file would never see, and the dependencies would be tracked in the jam file through the JNI header files themselves. Unfortunately, I have not found a simple way to declare a rule that takes N source files (the Java sources) and produces M target files (the JNI headers) where M is not one. I'm sure a boost.build wizard could do this, but I'm just a newbie. For now, I can easily live with the occasional wasted build time. (2) I would like my ant script to generate the JNI headers into the build directory, along with all the other products of the build, and that is straightforward to do. (I pass the path to the Parliament.jar file as a parameter to the ant script, and it can figure the rest out from there.) However, if I do this, then the lib target can't find the JNI headers while building its sources. What I would like to do is add a usage requirement of "<include>$(<:D)" to the jar file rule, but $(<) does not appear to have the same meaning at that point in the jam file as it has inside the jar file's action. Is there a way for the jar file's rule to add the build directory to the lib target's <include> feature? (3) The normal glob-tree rule will only recurse within the project directory, but my java sources don't live there. After some spelunking through the boost.build sources, I discovered path.glob- tree, which takes an extra argument for the directory in which the recursive search is rooted. Is it kosher to use path.glob-tree? If not, I would suggest that the normal glob-tree should take a third argument as well -- it's overly restrictive to assume that all recursive file searches will be rooted in the project directory. Again, thanks everyone for your help on this little adventure of mine. -Ian ========================= import make ; import path ; project /KB/KbCore ; path-constant JavaSrcDir : ../java ; lib Parliament :[ glob *.cpp : Utf8StaticInitGen.cpp ] /site-config//BerkeleyDB /site-config//JavaJNI :<include>. <define>BUILDING_KBCORE <define>PARLIAMENT_RSRC_AS_UTF16 <define>_REENTRANT <threading>multi <dependency>Parliament.jar :# default build :<include>. ; explicit Parliament.jar ; make Parliament.jar : [ path.glob-tree $(JavaSrcDir) : *.java ] : < at >BuildJar ; actions BuildJar { ant -DtargetJarPath=$(<) } _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build Ian Emmons 2008-12-01T19:34:09 http://permalink.gmane.org/gmane.comp.lib.boost.build/19830 Where did you got that configure from? Use *nix packages -- those with .tar.gz or .tar.bz2 extension. - Volodya _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build Vladimir Prus 2008-12-01T17:24:52 http://permalink.gmane.org/gmane.comp.lib.boost.build/19829 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build Oliver Zheng 2008-12-01T17:20:57 http://permalink.gmane.org/gmane.comp.lib.boost.build/19828 Hello, here's what I'm trying to do: gcc /DGR_BUILD_TIME=1228135248 ... GR_BUILD_TIME is the output of date +%s. I read the manual and tried this: local GR_BUILD_TIME = [ SHELL "date +%s" ] ; # project settings ################################################### project : requirements <include>. # GCC settings <define>GR_BUILD_TIME=$(GR_BUILD_TIME) . . . Now, GR_BUILD_TIME is passed to gcc but it contains a trailing newline, which causes the compile to fail like this: georog-dev:/home/daniel/projects/trunk/GeoROG> bjam toolset=gcc-4.1.1 -q ...patience... ...patience... ...found 4676 targets... ...updating 4 targets... gcc.compile.c++ bin/gcc-4.1.1/debug/GCore.o g++: no input files /bin/sh: -Ibin/gcc-4.1.1/debug: not found "g++" -ftemplate-depth-128 -O0 -fno-inline -Wall -g -fPIC -Winvalid-pch -DBOOST_BUILD_PCH_ENABLED -DGR_BUILD_TIME=1228135248 -I"bin/gcc-4.1.1/debug" -I"." -I"../GFL" -I"../SBGFLTK/include" -I"/home/daniel/projects/Vendor/Boost/include/boost-1_37" -I"/usr/include/glib-2.0" -I"/usr/lib/glib-2.0/include" -c -o "bin/gcc-4.1.1/debug/GCore.o" "/home/daniel/projects/trunk/GeoROG/GCore/GCore.cpp" ...failed gcc.compile.c++ bin/gcc-4.1.1/debug/GCore.o... ...failed updating 1 target... There's a newline right after -DGR_BUILD_TIME=1228135248, which is why the line after is being treated as a command. How can I accomplish this? I'm using Milestone12 with Boost.Jam Version 3.1.13. OS=LINUX. Thanks in advance! Daniel Lidström 2008-12-01T12:49:20 http://permalink.gmane.org/gmane.comp.lib.boost.build/19827 Hi, assuming I've got an install target (installing executables) inside the fictive project A's Jamroot: I'd like to declare an install target inside a dependent project B, which installs the contents of project A's install target alongside with the local installation contents. Example: - Project A installs a.exe to e.g. /projA/bin/a.exe - Project B installs b.exe to e.g. /projB/bin/b.exe - The latter should also include project A's a.exe target installation to /projB/bin/a.exe Is there a way of doing this by simply referring to a single target defined within project A? I guess it would be possible to explicitly refer to specific targets from project B, e.g. "/projA/src/a/Jamfile//a", but I'd like project A to define what dependent projects gets to install. TIA / Johan _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build Johan Nilsson 2008-12-01T09:07:27 http://permalink.gmane.org/gmane.comp.lib.boost.build/19826 Hi there! I'm trying to let the BBv2 create symlinks to generated stubs and skeletons into the source folder, but unsuccessfully yet. This is needed to simplify code browsing and assistance in vim or Eclipse. Let's start from the following tao.idl: ############## Begin of tao.idl ########### import generators ; import type ; import feature : feature ; import toolset : flags ; type.register IDL : idl ; type.register INL : inl : H ; type.register SYM_LINK ; feature <symlink-sources> : : free path ; generators.register-standard tao.tao-idl : IDL : CPP(%S) H(%S) CPP(%C) H(%C) INL(%S) INL(%C) ; flags tao.tao-idl SYMLINK_SOURCES <symlink-sources> ; rule tao-idl ( dstS dstS_h dstC dstC_h inlS inlC : src : properties * ) { INCLUDES $(dstS) : $(dstS_h) ; INCLUDES $(dstC) : $(dstC_h) ; } actions tao-idl { tao_idl -o $(<[1]:D) $(>) symlink=$(SYMLINK_SOURCES) if [ "$symlink" ]; then for i in "$(<[1]:D)"/*.{cpp,h,inl}; do ln -sf "$i" $symlink/`basename "$i"` done fi } ########### End of tao.idl ################### It allows us to build TAO applications (almost) perfectly: ############# Begin of Jamfile ############### import tao ; lib Foo_idl : Foo.idl : <link>static <symlink-sources>. ; exe FooServer : [ glob *.cc ] Foo_idl TAO_PortableServer ; ############# End of Jamfile ################ The desired symlinks are created by the actions tao-idl. Unfortunately, they are left after doing 'bjam clean'. So I tried to create them legally extending default generator (the idea was taken from tools/stage.jam, shared libraries): ############# Begin ################### class sources-from-idl-generator : generator { rule __init__ ( ) { generator.__init__ tao.tao-idl : IDL : CPP(%S) H(%S) CPP(%C) H(%C) INL(%S) INL(%C) ; } rule run ( project name ? : property-set : source : multiple ? ) { local result = [ construct-result $(source) : $(project) $(name) : $(property-set) ] ; local generated = [ generated-targets $(source) : $(property-set) : $(project) $(name) ] ; local loc = [ $(project).location ] ; for local file in $(generated) { local name = [ $(file).name ] ; local link = $(loc)/$(name) ; result += [ symlink $(link) : $(project) : $(file) : $(property-set) ] ; } return $(result) ; } rule symlink ( name : project : source : properties ) { local a = [ new action $(source) : symlink.ln : $(properties) ] ; local targets = [ new file-target $(name) exact : SYMLINK : $(project) : $(a) ] ; return $(targets) ; } } generators.register [ new sources-from-idl-generator ] ; ################################################## The needed generators are created, but obviously they aren't called during the build. And I can't figure out how to request them. What am I missing? How to create those symlinks and to have them removed after cleaning? — Anatoli Sakhnik _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build Anatoli Sakhnik 2008-12-01T08:50:39 http://permalink.gmane.org/gmane.comp.lib.boost.build/19825 [direct cc as it's been a while since last posting] Vladimir Prus wrote: [snip] Ok, combining the following steps "works": - Register TCL type - Adding <install-type>TCL to current install target - Adding the script to the current install target's sources (by globbing) Does not feel right, though (see further below). That approach doesn't really appeal to me. Ok, so in my case (after modifications above) I produced a target named xxx.tcl of type TCL. How come e.g. the exe/lib rules have targets specified without extension - what is the magic incantantion? I'd like to be able to do something similar for the TCL (or other script) files. A little backgrounder; in this project the convention is to have a "main" target inside each subproject, named as the containing project directory, e.g. "<root>/src/apps/fooapp/build/Jamfile" contains an installable target named "fooapp". By keeping to this convention I can automate the adding of targets for installation inside Jamroot; I'd like to be able to do this in the same way for my script-based application(s). How can I implement this (preferably by adding nothing else than <install-type>TCL to my Jamroot, for the install target)? Thanks / Johan _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build Johan Nilsson 2008-12-01T08:53:45 http://permalink.gmane.org/gmane.comp.lib.boost.build/19824 Try asking wikipedia... Note, the answer is off-topic. Rene Rivera 2008-11-30T21:30:06 http://permalink.gmane.org/gmane.comp.lib.boost.build/19823 Steven, Thanks for your help. On Nov 29, 2008, at 1:05 PM, Steven Watanabe wrote: I haven't had time to try this yet, but I will soon. I may well be able to use this as a starting point for doing fewer of the build steps in the ant script and more in the jam file, which is probably the right way to do this anyway. (Ultimately, it would be great to extend boost.build so that it has built-in support for JNI header generation, and even Java compilation.) That works! You're right, it wouldn't help at all. That was an ill-considered newbie comment -- sorry. One more question: What does AMDG stand for? Thanks again, Ian _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build Ian Emmons 2008-11-30T21:12:53 http://permalink.gmane.org/gmane.comp.lib.boost.build/19822 Volodya, Again, thanks for your help. On Nov 29, 2008, at 1:57 PM, Vladimir Prus wrote: In this particular case, my ant script does dependency checking of its own, so it doesn't regenerate the JNI headers unless one of the Java sources has changed. Thus, even though ant runs every time, the ideal behavior would be that dependents of this notfile target would be unaffected by the fact that it ran. But I'm sure that someone else has another case where the fact that the notfile target always runs means that some dependency is always getting updated, and therefore the current behavior is desired. I guess the ideal would be two kinds of notfile targets, one that behaves as-is, and another (notfile-no-force, perhaps?) which never forces dependent targets to be rebuilt. Then the writer of the notfile target can choose the correct one. Another resolution to my particular problem is to realize that I'm an old hand at ant scripts and a newbie to boost.build (which is pretty darn slick, BTW). So in my haste to get my build working, I'm trying to do the Java part with the most familiar tool, when it might be better for me to figure out the make and generate rules so I can do the whole thing in the jam file. Ultimately, as I mentioned in my reply to Steven, it would be great if boost.build could have out-of-the-box support for Java builds and JNI headers. Thanks again, Ian _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build Ian Emmons 2008-11-30T21:12:50 http://permalink.gmane.org/gmane.comp.lib.boost.build/19821 I'm trying to create an alias rule that will override/set certain pdf generation properties, for example: alias type_traits : $(boost-root)/libs/type_traits/doc//standalone : $(COMMON_PDF_SETTINGS) ; But $(COMMON_PDF_SETTINGS) don't get passed down to the pdf build. Same result if I spell out the settings explicitly: alias type_traits : $(boost-root)/libs/type_traits/doc//standalone : <xsl:param>body.start.indent=0pt ; Any ideas on this? Also, I would like if possible to be able to control the file name under which a pdf gets installed: I can use the "install" rule to copy the pdf to a location of my choice, but the resulting file name isn't always quite what I would like... is there any kind of rename-rule I can use? Many thanks, John. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build John Maddock 2008-11-30T12:18:37 http://permalink.gmane.org/gmane.comp.lib.boost.build/19820 Trac ticket #2552, including a test case. Jon Biggar 2008-11-29T21:53:17 http://permalink.gmane.org/gmane.comp.lib.boost.build/19819 But on the other hand, while always running 'ant' might be reasonable, I am not sure that causing dependents of notfile to be always rebuilt makes sense. I guess I can make it not happen -- does that seem right? - Volodya Vladimir Prus 2008-11-29T18:57:39 http://permalink.gmane.org/gmane.comp.lib.boost.build/19818 AMDG Ian Emmons wrote: notfile targets are always built. You can try something like: make JniHeaders.txt : : < at >BuildJniHeaders ; alias JniHeaders : JniHeaders.txt ; actions BuildJniHeaders { ant jniHeaders echo Updated >$(<) } so that bjam has something to check the timestamp of. explicit JniHeaders ; How would that help? In Christ, Steven Watanabe _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build Steven Watanabe 2008-11-29T18:05:45 http://permalink.gmane.org/gmane.comp.lib.boost.build/19817 On Nov 29, 2008, at 3:02 AM, Vladimir Prus wrote: Thanks for the quick reply. Your suggestion does indeed cause the JniHeaders target to run before the library is built, but it has two undesirable side effects: * It causes the library is completely rebuilt every time, as if I did a bjam --clean beforehand. * It causes the JniHeaders target to run after the library is built as well (i.e., it runs twice). It would be nice if the lib rule could just ignore source dependency targets of unknown type. Thanks, Ian _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build Ian Emmons 2008-11-29T17:53:23 http://permalink.gmane.org/gmane.comp.lib.boost.build/19816 Hi Ian, ... Yes, JniHeaders indeed has no type -- which is fine. But then, you're adding it as sources of the 'lib' target, and the 'lib' target has no idea what to do with targets of unknown type. Probably, instead of adding the target to sources, you can use <dependency>JniHeaders in requirements? - Volodya Vladimir Prus 2008-11-29T08:02:33 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.lib.boost.build