[NB: these are frm's personal notes, NOT anything "official"]

1) [There's absolutely no reason to follow this, really - VS] I strongly suggest to follow the wxWidgets folder "design" in all your bakefile-based projects: you should create a BUILD folder in the root of the project and then put a BAKEFILES and MSW subfolders in it. In the end, it should look like:

 my_project_root
 |-- build
 |   |-- bakefiles
 |   |-- msw
 |
 |- Makefile.in
 |- autoconf_inc.m4
 |- GNUMakefile
 |- ...

obviously you should put all your bakefiles into BAKEFILES and win32 IDE projects and makefiles into MSW. Autoconf and GNU stuff should go instead directly in the root folder of the project. This makes much more autoconf-compliant the package.

2) [Outdated - VS] Bakefile's supported formats can be divided in three main categories: IDE project files, win32 command-line makefiles, unix makefiles. To be more specific, for Bakefile version 0.1.9, the IDE project formats are cbuilderx, msevc4prj, msvc6prj; the win32 command-line makefiles are borland, dmars, mingw, msvc, watcom. It results quite useful to define two variables in your bakefiles:

    <set var="TARGETING_WIN32" overwrite="0">
        <!-- FIXME: this is broken! autoconf can target win32 too -->
        <if cond="FORMAT=='autoconf' or FORMAT=='gnu'">0</if>
        <if cond="FORMAT!='autoconf' and FORMAT!='gnu'">1</if>
    </set>
    
    <set var="TARGETING_IDE" overwrite="0">
        <!-- FIXME: this is broken! use FORMAT_SUPPORTS_* variables instead -->
        <if cond="FORMAT=='msvc6prj' or FORMAT=='cbuilderx' or FORMAT=='msevc4prj'">0</if>
        <if cond="FORMAT!='msvc6prj' and FORMAT!='cbuilderx' and FORMAT!='msevc4prj'">1</if>
    </set>

to make distinctions between these categories; the utils bakefile already contains a definition of those two variables.

3) If you have multiple bakefiles in different BUILD/BAKEFILES folder scattered around your project's folders, you should redirect the autoconf include macros all in the same file: in all your Bakefiles.bkgen files you should add a piece like this:

    <add-flags formats="autoconf">
	<!-- bakefile will merge the conditions required by our Makefile.in with
             the conditions required by the others Makefile.in files of the project;
             wonderful ! -->
        -DAUTOCONF_MACROS_FILE=$(MYPROJECT_BASEDIR)/autoconf_inc.m4
    </add-flags>

supposing that MYPROJECT_BASEDIR is a variable pointing to the root folder of your project. In conclusion: you typically should have a single configure script generated using autoconf and thus you should have a single configure.in/configure.ac file which configures the entire project (i.e. all Makefile.in files). To be sure all the makefiles will be generated correctly, you must be sure to redirect all AUTOCONF_MACROS_FILEs all in the same file which you use to generate your unique configure script.

4) Do not use a single long bakefile for your project: the usual rules of modularity & easy code-maintenance applies to bakefiles, too !

I usually keep the templates I use (like basic.bkl, wxbase.bkl, utils.bkl) separed (so that they can be easily updated).

Another important thing to keep divided from actual build tags is the source & headers list: you should create a file (something like 'sources.bkl') where you declare a couple of variables (like 'MYPROJECT_SRC' and 'MYPROJECT_HDR') and then include it in your main bakefile. This is because when your project gets bigger, you'll probably need to create some script to automatically-generate that file.

5) Bakefile build system is typically used to build a project inside its tree structure: that is, the object files and all other generated files tipically goes into the project folders. This can be annoying when using CVS since it forces you to clean the project tree before each CVS commit/update or to ignore a long list of files created by the MAKE processes (e.g. all .OBJ files). This can be easily solved using .cvsignore files: look at the official CVS manual for more info on this. Since you'll probably use Bakefile to test builds with different compilers, you'll end up with long .cvsignore files which are scattered in your project's folders and thus force you to continuosly add new ignore-patterns to exclude all the compilers' useless stuff. Using BorlandC++, Mingw, GCC, MSVC++ compilers, I've found out that my typical .cvsignore file looks like:

.bakefile_gen.state
.deps
autom4te.cache
config.status
config.log
Makefile
bk-deps
*.a
*.lib
*.pdb
*.dll
*.exp
*.so*
*.obj
*.o
*.log
*.manifest*
*.pch
*.opt
*.ncb
*.plg
*.ncb
*.aps
*.suo
*.user
*.il?
*.tds
*.idb
*.map

you can safely create your .cvsignore files with the previous list as beginning and add your project-specific files-to-ignore list at the end. However, keep in mind that there are also other ways to tell CVS to ignore files; you can: - create a per-repository 'cvsignore' file in the CVSROOT of your project: it will affect all folders of your project - create a per-user list in `.cvsignore' in your home directory: it will affect all the CVS operations done by your user - set the environment variable $CVSIGNORE

Personally I find that the most comfortable option is to create a per-user list; you can do it also on win32 (with TortoiseCVS, right-click in a windows explorer window and choose CVS->Preferences->Ignored Files; then copy & paste the list above in the TortoiseCVS ignored file textbox)...