buildtool-devel Mailing List for Buildtool (Page 3)
Status: Alpha
Brought to you by:
jmmv
You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
(1) |
Jul
|
Aug
(17) |
Sep
(9) |
Oct
(3) |
Nov
|
Dec
(2) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(7) |
Feb
(3) |
Mar
(3) |
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
(4) |
Sep
(2) |
Oct
(1) |
Nov
(1) |
Dec
(1) |
2005 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
(1) |
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
(3) |
Dec
(1) |
2006 |
Jan
(2) |
Feb
(1) |
Mar
(2) |
Apr
(1) |
May
|
Jun
(11) |
Jul
(1) |
Aug
(4) |
Sep
(3) |
Oct
(1) |
Nov
|
Dec
|
From: Julio M. M. V. <jm...@me...> - 2003-09-17 10:12:07
|
On 16 Sep 2003 12:50:36 -0400 Doug Henry <dou...@xo...> wrote: > The depend routine doesn't seem to pick up changes in all the > dependencies. The dependencies get created correctly in the .dep file, > it just doesn't seem to check them all. I attached a very small sample > project. Basically there is an include and src directory. If you touch > any of the .c files the deps get rebuilt, but touching the *.h files > does nothing. Hmm... I noticed this problem recently too. Although, when the initial code was added, it worked fine. Something got broken in the meantime; will investigate it. Thanks! -- Julio M. Merino Vidal <jm...@me...> The NetBSD Project - http://www.NetBSD.org/ |
From: Julio M. M. V. <jm...@me...> - 2003-09-17 10:10:26
|
On 15 Sep 2003 16:53:17 -0400 Doug Henry <dou...@xo...> wrote: > It seems that 0.14 builds correctly using bison or byacc. The only > problem you might run into is that most linux systems have bison > installed and not byacc (by default anyway). In that case yacc is a > script that runs "bison -y". The comment for the -y option is "emulate > POSIX yacc". Bison run in this fashion results in the error listed at > the bottom of this email. Since it works with bison, maybe have the > configure script check for bison first, and if it is not installed check > for yacc next. After investigation, it seems that the '=' operator used in arith.y to define expressions is not needed at all. I've removed it, and now it builds fine with either yacc, or bison, or bison -y, or whatever (I hope ;). > Also, if bt_sh fails to build you still get the > successfully complete message, and it installs just fine. The first > time you see that there was a problem is when you go to use buildtool > and it tells you it can't find bt_sh. Yes, this problem has existed for a very long time. It's fixed now. Thanks! -- Julio M. Merino Vidal <jm...@me...> The NetBSD Project - http://www.NetBSD.org/ |
From: Doug H. <dou...@xo...> - 2003-09-16 16:56:08
|
an even easier test. build the testsuite that comes with buildtool. Then do the following. touch lib/*.h buildtool build Neither the library or program rebuild. |
From: Doug H. <dou...@xo...> - 2003-09-16 16:50:43
|
The depend routine doesn't seem to pick up changes in all the dependencies. The dependencies get created correctly in the .dep file, it just doesn't seem to check them all. I attached a very small sample project. Basically there is an include and src directory. If you touch any of the .c files the deps get rebuilt, but touching the *.h files does nothing. |
From: Doug H. <dou...@xo...> - 2003-09-15 20:53:27
|
It seems that 0.14 builds correctly using bison or byacc. The only problem you might run into is that most linux systems have bison installed and not byacc (by default anyway). In that case yacc is a script that runs "bison -y". The comment for the -y option is "emulate POSIX yacc". Bison run in this fashion results in the error listed at the bottom of this email. Since it works with bison, maybe have the configure script check for bison first, and if it is not installed check for yacc next. Also, if bt_sh fails to build you still get the successfully complete message, and it installs just fine. The first time you see that there was a problem is when you go to use buildtool and it tells you it can't find bt_sh. arith.y:68.14: syntax error, unexpected "=" arith.y:74.40: syntax error, unexpected "=" |
From: Julio M. M. V. <jm...@me...> - 2003-09-02 17:27:50
|
On 02 Sep 2003 12:39:54 -0400 Doug Henry <dou...@xo...> wrote: > I get this problem when building 0.13: > > /usr/bin/bison arith.y > mv y.tab.c arith.c > mv: cannot stat `y.tab.c': No such file or directory > > The output from bison on my machine is arith.tab.c and not y.tab.c. I > am using bison 1.35. I also have bison 1.35 on a Debian 3.0 system, but this problem doesn't show up. I guess this happens because your system is calling bison with the 'bison' name and mine is calling it with the 'yacc' symlink. Anyway, this will be fixed in 0.14 (or in CVS in a minute ;). Thanks. -- Julio M. Merino Vidal <jm...@me...> The NetBSD Project - http://www.NetBSD.org/ |
From: Julio M. M. V. <jm...@me...> - 2003-09-02 17:23:50
|
On 02 Sep 2003 12:55:03 -0400 Doug Henry <dou...@xo...> wrote: > after about 0.9 the console messages are in a short/hidden format. Is > there a flag I can set to get verbose messages back in order to debug > the command being executed. Basically, I need to see the compile line. If you are still using bt_make, enabling the developer mode will turn bt_wrap's logging functionality on. A .bt_wrap.log file will be created in each directory with the command line given to it and the real command beeing executed. If you are using the new bt_logic, this can't be done in 0.13, sorry. There is an item in TODO, and I'll give high priority to it. May be a command line flag with the ability to specify multiple output levels on screen could be good. I hope to release 0.14 soon, to fix some bugs in 0.13, and that will probably be after logging is implemented. Cheers. -- Julio M. Merino Vidal <jm...@me...> The NetBSD Project - http://www.NetBSD.org/ |
From: Doug H. <dou...@xo...> - 2003-09-02 16:54:46
|
after about 0.9 the console messages are in a short/hidden format. Is there a flag I can set to get verbose messages back in order to debug the command being executed. Basically, I need to see the compile line. |
From: Doug H. <dou...@xo...> - 2003-09-02 16:39:41
|
I get this problem when building 0.13: /usr/bin/bison arith.y mv y.tab.c arith.c mv: cannot stat `y.tab.c': No such file or directory The output from bison on my machine is arith.tab.c and not y.tab.c. I am using bison 1.35. |
From: Julio M. M. V. <jm...@me...> - 2003-08-31 20:47:09
|
Hi, I'm pleased to announce that the 0.13 version of Buildtool has been released. As usual, you can find it in the homepage: http://buildtool.sourceforge.net/ This version means a radical change over the previous ones with respect to files needed to control a package. The main highlights include: * The bt_sh module, an integrated shell interpreter. This doesn't affect you directly, but you won't have to care about shell portability any more ;) * The buildtool.d directory is no longer recognized. Buildtool will now use a single file, Generic.bt, placed in the top level directory of your project. This file is splitted up into functions, which have similar functionality to the independant files. The conversion is very straigforward; see below. You must do this change in your project if you want to use 0.13. * A new make-like tool has been added, bt_logic, which will eventually deprecate bt_make (together with bt_logic). Both systems are kept now, so your Makefile.bt files will still work. Anyway, I recommend you switching to the new Logic.bt files as soon as possible to detect missing functionality and bugs. I know these changes are a PITA. Therefore, I have written a script that tries to convert a 0.12 project to a 0.13 one. This script will be launched whenever you execute "buildtool <something>" inside a 0.12 project; it will ask you if you want to proceed, and then it will write a new Generic.bt file. You will doubtly have to touch this (except for indentation issues). OTOH, converting from Makefile.bt to Logic.bt is a bit more difficult. The script will tell you what to do (run "buildtool make tologic") when it's time to do so, but the conversion may lack some details. If you have only used standard features, it should be able to do an accurate conversion. As examples of Logic.bt files, you can check out the testsuite or the buildtool-doc package. Both have been converted to the 0.13 framework. The main problem maybe is that there is no real documentation for bt_logic yet; it is likely to change in some aspects, so writting good docs now could be silly. Anyway, the distribution comes with a file, bt_logic/NOTES, that includes several notes with respect to bt_logic. If you know makefiles, you should be able to switch your mind easily. I've decided to release 0.13 now so that developers using it for their own projects can start migrating them to the new framework, if possible. If this can't be accomplished by some feature missing in the actual code, it can be easily (and sooner) introduced in the next version. As soon as people can migrate their own projects to the new framework, compatibility will be dropped (that is, bt_make and bt_wrap will be removed), thus decreasing Buildtool's size by around a 45%. At last, the actual codebase has been tested in NetBSD, Solaris, Darwin, Gentoo Linux and Debian Linux, and all portability issues have been hopefully fixed (aside from shared library building, which is still in the TODO). If you have any trouble in the conversion, please let me know. Suggestions and bug reports will be welcome too. Good luck! -- Julio M. Merino Vidal <jm...@me...> The NetBSD Project - http://www.NetBSD.org/ |
From: Julio M. M. V. <jm...@me...> - 2003-08-25 20:00:41
|
On Sun, 24 Aug 2003 02:10:12 -0700 Rusty Ballinger <ho...@sb...> wrote: > Hey, the example buildtool.d/docs file generated by buildtool wizard > starts with > > # $Id: ... $ > # > # buildtool.d/docs file. > # > > CHANGES - ... Yes, I know. That's a bug (fixed as a side-effect of other changes, see below). > but bt_doc doesn't seem to ignore the hashed-out lines. It should! > (That, or the example shouldn't have them, but I think it's > preferable to allow comments & to be able to comment out lines.) In CVS (next 0.13), I've sligthly changed the format of files (there is now a single one in the top level directory). Documents are added using a function instead of a hand parsed file from a shell function, so you can add conditionals or whatever you want :) (An automatic conversion script is provided, to make the change less painful). Cheers -- Julio M. Merino Vidal <jm...@me...> The NetBSD Project - http://www.NetBSD.org/ |
From: Rusty B. <ho...@sb...> - 2003-08-25 07:01:23
|
Hey, the example buildtool.d/docs file generated by buildtool wizard starts with # $Id: ... $ # # buildtool.d/docs file. # =20 CHANGES - ... but bt_doc doesn't seem to ignore the hashed-out lines. It should!=20 (That, or the example shouldn't have them, but I think it's preferable to allow comments & to be able to comment out lines.) (this is with version 0.12) --Rusty |
From: Julio M. M. V. <jm...@me...> - 2003-08-22 12:16:08
|
Hi all, it is known that make's syntax and behavior is confusing to new users, and even sometimes to experienced ones. OTOH, the .mk files that come with Buildtool have many flaws, beeing the most annoying the impossibility of building several different things in the same directory. Another detail is, while all Buildtool is shell-script based, makefiles have their own syntax. I've started working on a new make-like program, mainly because of the reasons listed above (between others). Its name, bt_logic (yes... the old functionality of this module has been moved to bt_wrap). The program is beeing written entirely in shell script language (well, with some helper tools in C). Scripts controlling it are shell script too. Since yesterday, it is living in the CVS repository (because I want to keep history) and moving quite fast. It kinda works: it is able to track deps between files, generate dependancy files (with a new syntax) execute the common stages "build", "clean", "cleandir" and "install"... Feel free to try it, though don't expect it to work fine. 1) you will *need* pdksh; 2) the compiler is beeing called directly, so don't expect it to work on "strange" systems (I've only tried it in NetBSD and Debian for now9. The testsuite includes now the new scripts (Logic.bt). The bt_logic module is now executed with "buildtool build", "buildtool clean", and so on. bt_make will be kept until bt_logic works well; you can still execute it as always with "buildtool make". Buildtool will include both modules for some versions probably (such a change can't be made too drastically...). The program is very inefficient for now. Speed will be hopefully improved after the module works fine and its code is cleaned up. About a sentence I said above "you will need pdksh"... it will be very difficult, if not impossible, to make this module work with any shell, mainly because non-posix functionality is needed. I'm thinking about importing a trimmed version (no interactive editing, for example) of pdksh (or NetBSD's sh, which is faster) inside buildtool, so we don't have portability issues and we have the freedom to extend the shell syntax as we want (imagine a '+=' operator, for example, or the test command beeing a builtin command to gain speed). And now, some notes about how build scripts are expected to work: There are three main concepts: stages, types and targets. Stages are the well-known build, install, clean and cleandir. Targets are things that can be built (a program, a library, an object file, a dependancy file, etc). And types (program, library, etc) associate a set of actions for each stage to a given target. So you can execute each stage independantly on each target. For example, a simple Logic.bt file: logic() { bt_target prog1 prog2 prog3 } target_mylib() { BT_TYPE="library" BT_SOURCES="mylib.c" } target_prog1() { BT_TYPE="program" BT_DEPENDS="mylib" BT_LIBS="./mylib.a" BT_SOURCES="prog1_foo.c prog1_bar.c" } target_prog2() { BT_TYPE="program" BT_SOURCES="prog2_foo.c prog2_bar.c" } target_prog3() { BT_TYPE="program" BT_SOURCES="prog3_foo.c prog3_bar.c" } post_build() { echo "SAMPLE MESSAGE: ALL BUILDS FINISHED" } With this simple script you could do the following: $ buildtool build prog1 (which builds lib and prog1 only) $ buildtool build (which builds all of the three programs) $ buildtool cleandir prog2 prog3 (which cleans prog2 and prog3 only) and so on. There are also automatic targets, so you could do: $ buildtool build prog3_foo.o which automatically creates the object file based on the source file (like make .c.o conversions). Or: $ buildtool build src which, if 'src' is a directory, could switch to it and rebuild all targets inside it (which means that directories are treated as regular targets). And you could even have: target_prog3_foo.o_pre_build() { # extra commands needed to create the prog3_foo.o target file. } I hope you get the idea ;) (look at the testsuite for a working example). Lots of things may change until it's stabilized. When it's ready, I will try to prepare a script to easily convert from Makefile.bt files to Logic.bt Integration with bt_wrap is still to be done, so that we can wrap calls to the compiler and remove or add needed flags. Any comments will be highly appreciated. Thanks for your attention :) -- Julio M. Merino Vidal <jm...@me...> The NetBSD Project - http://www.NetBSD.org/ |
From: Julio M. M. V. <jm...@me...> - 2003-08-19 08:41:12
|
On Mon, 18 Aug 2003 21:51:41 -0700 Rusty Ballinger <ho...@sb...> wrote: > > There isn't. Could you explain what does automake's check target in > > detail? I know nothing about it. Thanks. > > In any subdir's Makefile.am, you can list one or more programs in > TESTS (typically shell scripts, I thought, but the automake info page > says you can use compiled programs, too): > > TESTS = test-foo test-bar test-baz > > When you do a top-level "make check", it recurses through the tree, > builds any of those test programs which haven't been built yet, and > runs them each once. At the end, it tells you how many passed & how > many failed. > > (It also has support for "DejaGNU tests", but I don't know anything > about that.) Aha, it sounds quite interesting. > (There may be some better way to run buildtool in a makefile?) There isn't, but could be good to have. Anyway... I have started working on a replacement for bt_make. It is (for now) shell based, with a syntax simpler than the one in make (well... it is very inmature, but I have some ideas in mind ;). It will probably be merged with bt_logic too, to make things a lot simpler (that is, avoid passing stuff from bt_make to bt_logic... everything could be done at once from the same program, as jam does, iirc). I don't know if this will get anywhere. If it does, I'll implement this in the new progarm. If it doesn't, this will get into the actual bt.*.mk files. Cheers -- Julio M. Merino Vidal <jm...@me...> The NetBSD Project - http://www.NetBSD.org/ |
From: Rusty B. <ho...@sb...> - 2003-08-19 05:42:44
|
> > Is there a buildtool analog to automake's "check" target, which > > recurses through the source tree, runs any test scripts specified in > > the various subdirectories, & prints a summary of the results? > > There isn't. Could you explain what does automake's check target in > detail? I know nothing about it. Thanks. In any subdir's Makefile.am, you can list one or more programs in TESTS (typically shell scripts, I thought, but the automake info page says you can use compiled programs, too): TESTS =3D test-foo test-bar test-baz When you do a top-level "make check", it recurses through the tree, builds any of those test programs which haven't been built yet, and runs them each once. At the end, it tells you how many passed & how many failed. (It also has support for "DejaGNU tests", but I don't know anything about that.) On the other hand, maybe "make check" doesn't get you much. If you don't care about the summary (I don't much), then you could get something similar with this (in your subdir's Makefile.bt): check: test-foo test-bar test-baz ./bt_run test-foo ./bt_run test-bar ./bt_run test-baz and at the top level: # "we know these directories have tests" check: (cd some/dir && buildtool make check) (cd some/other/dir && buildtool make check) (There may be some better way to run buildtool in a makefile?)=20 Anyway, that's not as nice as automake's support, but it's not hard to do manually. --Rusty |
From: Julio M. M. V. <jm...@me...> - 2003-08-18 18:29:56
|
On Mon, 18 Aug 2003 00:32:11 -0700 Rusty Ballinger <ho...@sb...> wrote: > Is there a buildtool analog to automake's "check" target, which > recurses through the source tree, runs any test scripts specified in > the various subdirectories, & prints a summary of the results? There isn't. Could you explain what does automake's check target in detail? I know nothing about it. Thanks. -- Julio M. Merino Vidal <jm...@me...> The NetBSD Project - http://www.NetBSD.org/ |
From: Julio M. M. V. <jm...@me...> - 2003-08-18 18:05:02
|
On Sun, 17 Aug 2003 23:56:12 -0700 Rusty Ballinger <ho...@sb...> wrote: > Hey, "buildtool make -dx" prints out the commands being run to build > files, but what that tells me is that "bt_logic -m compile" is being > run with a bunch of arguments. Is there a way to get bt_logic to say > exactly what command it's running? Enable developer mode at configuration time (i.e., --enable-developer). Aside from turning on several warning flags, it will add the -l flag to bt_logic. And the generated log file (.bt_logic.log) contains the exact command executed each time. > (On a slightly related note, it would be nice if "buildtool make > -help" listed the debug flags. That would save a trip to the users > guide...) That sounds good. I'll (probably) add it :) > The reason I care about the arguments being passed is, I wanted to > know whether some #define was being passed on the command line when > compiling so that I could tell whether my code was being built by > buildtool. (Like the way autoconf/automake passes -DHAVE_CONFIG_H? > I need to know whether to #include bt_config.h vs. config.h, and > there's that moc-file difference I mentioned in another thread.) I > guess it's easy enough to add my own -DUSING_BUILDTOOL or whatever to > BT_FLAGS_CPP in buildtool.d/config, though. The addition to BT_FLAGS_CPP sounds good enough. Anyway, if you want compatibility between the auto* tools and buildtool (without doing hacks to your code), you can add some stuff to the config script to generate a compatible config.h file. How? At the end of the process, simply do a 'cp'. And, after each check, define a new variable with bt_define and bt_define_unquoted renaming the variables to match the same auto* names. (I did this for a third party project, was ugly but worked ;). For example: if bt_check_func "poll"; then bt_define HAVE_POLL fi Cheers -- Julio M. Merino Vidal <jm...@me...> The NetBSD Project - http://www.NetBSD.org/ |
From: Rusty B. <ho...@sb...> - 2003-08-18 11:23:10
|
Hey, in the users guide, section 10.3.2, "Features", you might mention that the call to bt_feature has to be in your bt_config_script_init(), not your bt_config_script(). You might also mention in the output from "buildtool config --help" that the names of the features are not case-sensitive. --Rusty |
From: Rusty B. <ho...@sb...> - 2003-08-18 09:53:52
|
Hey, the bt_dist part of the users guide at http://buildtool.sourceforge.net/docs/manual/bt_dist.html should mention that it starts by doing a "make cleandir"! (That's a little surprising.) Also, I know this behavior is documented, but having the source tarball wind up in the parent directory is surprising too. While removing everything which doesn't belong & tar'ing up the result is interesting & in some ways neat, I found that I got a lot of crap (err, "spurious files") in my tarball. (backup files from my text editor, etc.) Do people usually cvs update a new copy of their tree for doing a bt_dist, or what? Would you consider adding support for some sort of DIST_FILES +=3D ... syntax which, if specified, causes *only* those files (plus the Makefile.bt) to be included in the tarball? (If DIST_FILES wasn't set in a Makefile.bt, all files from that directory would be included.) Or, better, for trees which use CVS, maybe you could use the CVS/Entries as the base list of files, and then DIST_FILES (or EXTRA_DIST or whatever) as additional files to include? That retains the ease-of-use of the current approach (what you get without having to do any work in your Makefile.bt is almost always right), eliminates the spurious files, and gives you the ability to add the occasional file which you don't want the end user to have to build.=20 (Err, but it means you can't use bt_dist on a tree you just unpacked, unless CVS/Entries is included in the tarball...) Anyway, if you go that route, it might be nice to let EXTRA_DIST contain globs, as maintaining the list of files generated by doxygen, for example, would be tedious. (Or maybe you don't have to do anything to support that, and people can go EXTRA_DIST =3D ${:!ls *.html *.css *.gif!}) --Rusty |
From: Rusty B. <ho...@sb...> - 2003-08-18 08:23:02
|
Is there a buildtool analog to automake's "check" target, which recurses through the source tree, runs any test scripts specified in the various subdirectories, & prints a summary of the results? --Rusty |
From: Rusty B. <ho...@sb...> - 2003-08-18 07:47:06
|
Hey, "buildtool make -dx" prints out the commands being run to build files, but what that tells me is that "bt_logic -m compile" is being run with a bunch of arguments. Is there a way to get bt_logic to say exactly what command it's running? (It looks like "bt_logic -l logfile" will do that, but the only way to add "-l logfile" to bt_logic's arguments is to edit bt.lib.mk? It would be nice if "buildtool make -dx" caused some environment variable to be set, which bt_logic would check for & print the command being run on stdout. Without something like that, is there any way for users to find out what flags are really being passed to the compiler?) (On a slightly related note, it would be nice if "buildtool make -help" listed the debug flags. That would save a trip to the users guide...) The reason I care about the arguments being passed is, I wanted to know whether some #define was being passed on the command line when compiling so that I could tell whether my code was being built by buildtool. (Like the way autoconf/automake passes -DHAVE_CONFIG_H?=20 I need to know whether to #include bt_config.h vs. config.h, and there's that moc-file difference I mentioned in another thread.) I guess it's easy enough to add my own -DUSING_BUILDTOOL or whatever to BT_FLAGS_CPP in buildtool.d/config, though. --Rusty |
From: Rusty B. <ho...@sb...> - 2003-08-18 06:37:04
|
> > 3. I want to do something similar with libraries. In a project which > > builds libraries in a bunch of different directories, I don't want > > to have to set "LD_LIBRARY_PATH=3D$PWD/path/to/lib1:\ =2E.. > As I understand it, you have a problem when executing the program witho= ut > installing it, right? This is what the "bt_run" script generated at > runtime is for. It will set LD_LIBRARY_PATH accordingly based on -L fl= ags > and then execute your program. (Hmm... I see now it's undocumented...) Yes, thanks, it looks like that will work for me. > > 4. Is there a way to build multiple libraries in one subdir? =2E.. > As a workaround, you can put all sources in a directory (without > Makefile.bt) and create multiple subdirectories, each one with a Makefi= le, > that refer to the sources and create libraries. (You can use the > '.include' sentence to avoid repeating makefile blocks, for example). OK, I think I'd rather take a look at how you did the ability to specify alternate install directories for individual headers in BT_INCS, and see if I can do something similar in bt.lib.mk for BT_LIB. > > 5. If I want to build a shared object which should be dlopen'ed (not > > linked with), and I want it to be called foo.so instead of > > libfoo.so, is it best to use bt.lib.mk, and do something like: > > > > BT_LIB_INSTALL =3D no > > foo.so: libfoo.so > > cp libfoo.so foo.so > > install: foo.so > > $(BT_INSTALL_LIB) foo.so $(mydir) > > > > or what? I think bt.lib.mk automatically prepends "lib" to the > > name. > > It does. The thing is that I didn't care about this scenario (because > I was not aware of it). I could include a new variable to avoid prepen= ding > the 'lib' string to names (see below) to solve this problem. Will look > at it. (To be clear, the reason I care about the specific filename is that I need to be able to pass the filename to dlopen(). That means either I need to be able to specify at build time *exactly* the name of the file which will be created, or figure out at run time what default name was chosen. I'd rather do it the first way!) > Your solution has a problem. You are assuming libraries will be called > *.so, but if you are building in Darwin, they will be dylib.*. This is > why *.btl files are created, but then, you can't parse them during the > Makefile to get the right binary name... *sigh* Either of these would be fine with me: - be able to specify the exact name of the output file, with a variable named BT_LIB_FILENAME or BT_LIB_OUTFILE or BT_LIB_CREATE or something. (BT_LIB_MAJOR would not be required when this is set?) This seems simpler to use than the alternative: - have bt.lib.mk define some variable containing the name of the library which was actually created, so that you can have your "real" target (foo.so or whatever) depend on it, and use it in the cp or ln or whatever. Also, the developer would have to set BT_LIB_INSTALL =3D no, and BT_INSTALL_LIB the "real" target? (Or BT_INSTALL_BIN, to keep from getting the version symlink too...) > > 6. I have a class defined in Foo.h and implemented in Foo.cpp. It's = a > > Qt QObject, so I have: =2E.. > Thinking a bit... I recall that you had to #include "Foo.moc" at the en= d > of the .cpp file, so they get compiled at once into the same object. OK, that explains it. (The other two build environments I've used for this project have both used moc to generate moc_Foo.cpp, and then compiled that into moc_Foo.o, and then linked Foo.o and moc_Foo.o into libfoo.so.) I think #including Foo.moc will work fine for me, and it seems simpler! Thanks. --Rusty |
From: Julio M. M. V. <jm...@me...> - 2003-08-17 19:27:46
|
On Sun, 17 Aug 2003 04:53:20 -0700 Rusty Ballinger <ho...@sb...> wrote: > Several questions; sorry about the length. > > 1. I need to pass -I flags to the compiler (in some cases, for Qt > headers; in others, for my own project's headers which are > #included by utilities & tests). Is the right way to do this to > fiddle with BT_FLAGS_CPP in buildtool.d/config, like this? > > BT_FLAGS_CPP="-I\$(BT_TOPDIR)/include $BT_FLAGS_CPP" > BT_FLAGS_CPP="$BT_FLAGS_CPP -I$QTINCDIR" > > Same question for -L flags; do I just fiddle with BT_LIBS and > BT_FLAGS_LD? This sounds good. Another solution could be to create a top Makefile.inc file (which is directly included by first level subdirectories) to contain these values. > This works: > > BT_FLAGS_CPP="-I$PWD/include $BT_FLAGS_CPP" > > but that means your tree is broken if you mv it after "buildtool > config". > Hmm... this doesn't matter... moving the directory will surely break the build. ATM, the configuration script stores absolute paths in many places. > 2. My library installs headers into $prefix/include/foo. Some of > those headers #include each other by going "#include <foo/Bar.h>" > etc. However, in my source tree, the headers are not located in a > directory named "foo"; the build needs to create symlinks (or > copies, if the system doesn't support them) from wherever/they/are > to $(BT_TOPDIR)/someplace/foo, so that I can build with > -I$(BT_TOPDIR)/someplace, and those #include <foo/Bar.h>'s will > find Bar.h. (Does that make sense?) So my question is, when For my own projects, I tend to layout source (header) files the same way they will be installed, to avoid this problem. There are many autoconf'ed projects that deal with this problem, I think (at least, they have header files in other places than the installed one), so you could check how they deal with the problem. > building a library, is using BT_INSTALL_SYMLINKS the best way to > "install" my headers into a temporary location used by the rest of > the build? It should work, but call the command later in the script (preferably after all checks) to be sure it's defined. > 3. I want to do something similar with libraries. In a project which > builds libraries in a bunch of different directories, I don't want > to have to set "LD_LIBRARY_PATH=$PWD/path/to/lib1:\ > $PWD/path/to/lib2:$PWD/path/to/lib3:...", I want each library to > create a symlink (or copy if necessary) from its directory to > $(BT_TOPDIR)/lib, so that I can just set $LD_LIBRARY_PATH to > $(BT_TOPDIR)/lib:$$LD_LIBRARY_PATH for testing without having to > "buildtool make install". Is it OK to use BT_INSTALL_LIB for > this, and is it OK to make the target which "installs" the library > depend on $(_LIBNAME), or what? As I understand it, you have a problem when executing the program without installing it, right? This is what the "bt_run" script generated at runtime is for. It will set LD_LIBRARY_PATH accordingly based on -L flags and then execute your program. (Hmm... I see now it's undocumented...) > 4. Is there a way to build multiple libraries in one subdir? I > haven't tried it, but it might be possible to get bt.lib.mk to do > most of its work in a loop, one iteration per element in BT_LIB. Don't expect it to work. Most of the bt.*.mk files were adapted from NetBSD's makefile infrastructure, and it doesn't allow multiple builds (theorically) in the same directory. It *might* work if you try, though; haven't tested myself. As a workaround, you can put all sources in a directory (without Makefile.bt) and create multiple subdirectories, each one with a Makefile, that refer to the sources and create libraries. (You can use the '.include' sentence to avoid repeating makefile blocks, for example). > 5. If I want to build a shared object which should be dlopen'ed (not > linked with), and I want it to be called foo.so instead of > libfoo.so, is it best to use bt.lib.mk, and do something like: > > BT_LIB_INSTALL = no > foo.so: libfoo.so > cp libfoo.so foo.so > install: foo.so > $(BT_INSTALL_LIB) foo.so $(mydir) > > or what? I think bt.lib.mk automatically prepends "lib" to the > name. It does. The thing is that I didn't care about this scenario (because I was not aware of it). I could include a new variable to avoid prepending the 'lib' string to names (see below) to solve this problem. Will look at it. Your solution has a problem. You are assuming libraries will be called *.so, but if you are building in Darwin, they will be dylib.*. This is why *.btl files are created, but then, you can't parse them during the Makefile to get the right binary name... *sigh* > 6. I have a class defined in Foo.h and implemented in Foo.cpp. It's a > Qt QObject, so I have: > > BT_LIB = foo > ... > BT_SRCS = Foo.cpp > BT_INCS = Foo.h > QT_HDRS = Foo.h > ... > .include <qt.moc.mk> > .include <bt.lib.mk> > .include <bt.inc.mk> > > Foo.moc gets generated, but it never gets compiled and linked into > libfoo.so. If I try adding Foo.moc to BT_SRCS, I get warnings > about "duplicate script for target 'Foo.o' ignored". What am I > doing wrong? qt.moc.mk was done quickly when I needed moc support in a project. It was introduced in 0.6 and hasn't been touched since then, so it may be buggy WRT latest changes in buildtool... Anyway... I hardly remember how this thing works. If you compile Foo.moc to get Foo.o, then you are overwritting the Foo.o created by Foo.cpp? Thinking a bit... I recall that you had to #include "Foo.moc" at the end of the .cpp file, so they get compiled at once into the same object. > One thing I like about buildtool is that its files and directory are > named differently enough that they don't collide with existing stuff, > making it easy to try out buildtool without breaking your project's > existing build. (My plan is to use both for a while and see what > people prefer, because I can.) If you'd gone with Makefile instead > of Makefile.bt etc., that wouldn't be so easy. It is difficult to make people switch everything they actually have working with something new. Making them coexist solves this ;) Hope this helps. -- Julio M. Merino Vidal <jm...@me...> The NetBSD Project - http://www.NetBSD.org/ |
From: Rusty B. <ho...@sb...> - 2003-08-17 12:44:14
|
Several questions; sorry about the length. 1. I need to pass -I flags to the compiler (in some cases, for Qt headers; in others, for my own project's headers which are #included by utilities & tests). Is the right way to do this to fiddle with BT_FLAGS_CPP in buildtool.d/config, like this? BT_FLAGS_CPP=3D"-I\$(BT_TOPDIR)/include $BT_FLAGS_CPP" BT_FLAGS_CPP=3D"$BT_FLAGS_CPP -I$QTINCDIR" Same question for -L flags; do I just fiddle with BT_LIBS and BT_FLAGS_LD? (Well, using "\$(BT_TOPDIR)" doesn't work; the BT_FLAGS_CPP definition comes out right in bt_config.mk, and "buildtool make -dx" shows the right -I flag being passed to the compiler, but then bt_logic fails with "BT_TOPDIR: command not found".) This works: BT_FLAGS_CPP=3D"-I$PWD/include $BT_FLAGS_CPP" but that means your tree is broken if you mv it after "buildtool config". 2. My library installs headers into $prefix/include/foo. Some of those headers #include each other by going "#include <foo/Bar.h>" etc. However, in my source tree, the headers are not located in a directory named "foo"; the build needs to create symlinks (or copies, if the system doesn't support them) from wherever/they/are to $(BT_TOPDIR)/someplace/foo, so that I can build with -I$(BT_TOPDIR)/someplace, and those #include <foo/Bar.h>'s will find Bar.h. (Does that make sense?) So my question is, when building a library, is using BT_INSTALL_SYMLINKS the best way to "install" my headers into a temporary location used by the rest of the build? 3. I want to do something similar with libraries. In a project which builds libraries in a bunch of different directories, I don't want to have to set "LD_LIBRARY_PATH=3D$PWD/path/to/lib1:\ $PWD/path/to/lib2:$PWD/path/to/lib3:...", I want each library to create a symlink (or copy if necessary) from its directory to $(BT_TOPDIR)/lib, so that I can just set $LD_LIBRARY_PATH to $(BT_TOPDIR)/lib:$$LD_LIBRARY_PATH for testing without having to "buildtool make install". Is it OK to use BT_INSTALL_LIB for this, and is it OK to make the target which "installs" the library depend on $(_LIBNAME), or what? 4. Is there a way to build multiple libraries in one subdir? I haven't tried it, but it might be possible to get bt.lib.mk to do most of its work in a loop, one iteration per element in BT_LIB. 5. If I want to build a shared object which should be dlopen'ed (not linked with), and I want it to be called foo.so instead of libfoo.so, is it best to use bt.lib.mk, and do something like: BT_LIB_INSTALL =3D no foo.so: libfoo.so cp libfoo.so foo.so install: foo.so $(BT_INSTALL_LIB) foo.so $(mydir) or what? I think bt.lib.mk automatically prepends "lib" to the name. 6. I have a class defined in Foo.h and implemented in Foo.cpp. It's a Qt QObject, so I have: BT_LIB =3D foo ... BT_SRCS =3D Foo.cpp BT_INCS =3D Foo.h QT_HDRS =3D Foo.h ... .include <qt.moc.mk> .include <bt.lib.mk> .include <bt.inc.mk> Foo.moc gets generated, but it never gets compiled and linked into libfoo.so. If I try adding Foo.moc to BT_SRCS, I get warnings about "duplicate script for target 'Foo.o' ignored". What am I doing wrong? One thing I like about buildtool is that its files and directory are named differently enough that they don't collide with existing stuff, making it easy to try out buildtool without breaking your project's existing build. (My plan is to use both for a while and see what people prefer, because I can.) If you'd gone with Makefile instead of Makefile.bt etc., that wouldn't be so easy. --Rusty |
From: Julio M. M. V. <jm...@me...> - 2003-08-04 13:03:10
|
On Mon, 4 Aug 2003 04:20:40 -0700 Rusty Ballinger <ho...@sb...> wrote: > Looking at using buildtool; here's some random feedback. > > Is there a "buildtool-users" list? (or is -devel the appropriate > place for that sort of thing?) (Heck, is the -devel list even used? > The archive at http://sourceforge.net/mail/?group_id=58564 only shows > two messages, both spam!) There is no -users list as there is no need for it *yet*. And about -devel... it will be used if people uses it, not if I want :p > Is there a list of existing projects which use buildtool somewhere? > If so, it would be nice to see that in the documentation, or on the > home page, etc., as it would be a useful source of examples, & it > would also be reassuring to people who are considering using > buildtool for their own projects. I know there are some people using Buildtool for their own projects, though I'm not aware of any of them beeing "public". AFAICT, there are two public packages using buildtool (both mine): - The buildtool-doc package, which contains the buildtool manual. Download it from the website. - The xmlcatmgr program: http://xmlcatmgr.sourceforge.net/ I'm using it for several other things (some C++ libraries mainly), but are not ready to be distributed. > There are some broken links in the manual at > http://buildtool.sourceforge.net/docs/manual/index.html ("User's > documentation", pt01.html; and "Developer's documentation, pt02.html) Fixed, thanks. > During development on buildtoolized projects, how do you guys avoid > getting RSI (not to mention brain damage) from having to type > "buildtool make" instead of just "make"? alias bt="buildtool" is my personal choice. > Do you tend to put little > Makefile wrappers around buildtool in every directory, like > all install uninstall clean foo bar ... : > buildtool make $@ That's ugly and will break if buildtool changes its calling syntax (which may happen. I'm considering "buildtool build" or "buildtool install", etc). > or "alias bake 'buildtool make'", etc.? > > When running "buildtool wizard", I found some of its questions > unclear: > - "Will you use the C language?" If my source files are all C++, is > the answer yes, or no? The next question is "Will you use the C++ language?" so answer no to the C one. > - "Do you need pkgconfig (not bt_pkgflags)?" C'mon, I've only been > using buildtool for 5 minutes; how do I tell? If you don't know what is it, you don't need it. This is mainly used by GNOME libraries/programs. > - "Do you need threads?" I'm not making pthreads calls myself, but I > know I'm linking against other libraries which do, so what's the > answer? You answer 'no', probably. The library you are using should link against whatever it needs, and you must not rely on this. (that is, dependancies should be hidden by the library you are using; if not, you or the library are doing something wrong). > - Similarly, "Do you need an X Window System?" Well, not directly, > but I'm linking with Qt, which does, so what do I need to answer > here? Same as above. > It would be nice if you could enter a "?" (or something) to get a > paragraph or two of explanation, and have the question repeated. Hey, bt_wizard is very young! > ARGHH!!! "buildtool wizard" shouldn't stomp your existing files! (I Good point, I'll probably add a question "Overwrite existing files?". Cheers -- Julio M. Merino Vidal <jm...@me...> The NetBSD Project - http://www.NetBSD.org/ |