Re: [bakefile-devel] Subprojetc question.

> > [I hope this is the correct way for talking about bakefile related
> > things]
>
> Yes, absolutely.

Before mailing here I already reported a bakefile bug on the wxWindows SF page,
should I duplicate it on the bakefile SF page as it is not specific to wxWin?

http://sourceforge.net/tracker/?func=detail&atid=109863&aid=876864&group_id=986
3

> > The issue; guidelib.bkl has a rule to make the lib and demo.bkl has
> > a rule to make the demo.exe, but because demo.bkl depends on the
> > guidelib it using <subproject id=3D"guidelib">
> >         <dir>../../</dir>
> >         <dependency-of>all</dependency-of>
> >     </subproject>
> > This way the lib gets build if needed (just the same as the wxWin
> > samples). But for some reason this doesn't work to well:
>
> I think there's a misunderstanding of what <subproject> is. It's a way=20
> to build another set of targets that don't depend on targets in the=20
> "parent" makefile (and a makefile of its own is created for=20
> subproject). If you have an executable target that depends on a=20
> library, then you should do something like this instead:
>
> <lib id=3D"guidelib">
> =2E...
> </lib>
>
> <exe id=3D"demo">
>    <library>guidelib</library>
> </exe>
>
> The <library> tag makes guidelib a dependency of demo and ensures=20
> correct linker settings.

No I understand (well I think I do) what subproject is for and what the
bakefile exe,lib,dll rule is for. The first version of my bakefile did it the
way you suggest above, but there are some problems doing it this way:
- The guidelib and demo dsp file will both be in the demo directory. But I want
one set of makefiles in the lib directory to build the lib and one set for each
sample/application using the lib in their directory.
- [I'm not sure the next issue is true, I don't remember correctly] Because of
the above issue also the object files etc get put into the sample directory...
meaning a rebuild is needed form the guidelib for every application using it. A
lot of space wasted...
- Another set of problems cam when I divided the bakefile in  3 parts, a common
part with standard defines and templates etc, a bakefile for the exe in the
demo dir and a bakefile for the lib in the lib directory.
* Because both the exe and the lib bakefile included the common part and the
exe bakefile included the lib bakefile it gave parse errors (bakefile couldn't
handle me defining the same set of options again).
*Also if I include a bakefile that has a list of files relative to that
bakefile in it I would end-up with wrong file paths. For example if the master
bakefile is not in the same directory as the sub bakefile the files will not be
found...

So that is why I want to use subproject instead of what you suggest. But as I
already reported this is OK for the makefiles but not for the MSVC6prj files.
Any other suggestions?


> > - MSVC demo.dsw doesn't include the guidelib.dsp file, why?=20
>
> Because you can't make a .dsw depency of another .dsw file and at the=20
> time demo.dsw is generated, nothing is known about the content of=20
> guidelib bakefile so it can't infer what dsp files there will be (so=20
> that it could make all of them dependencies).

Yeah I know a dsw can't depend on another dsw file, but sins the wx samples
parent directory seemed to build its dsw in this way, using the subproject tag
that is, I was under the impression that is was possible to make the sample exe
dsw file include and depend on the guidelib dsp file... It seems I
misunderstood some things if it isn't possible. Ooh well guess I need to study
those files some more then.

> > - The makefile generated for OW works fine (In other words it
> > builds the lib and the exe like I want) but for Borland it
> > generates the following wrong demo makefile rule:
>
> That's because there's no way (that I know) to save & restore current=20
> directory in Borland's make. Maybe it's possible to workaround it=20
> somehow, but I don't (yet) know how. The underlying cause is that=20
> <subproject> is meant to be used with subdirectories, not=20
> subdirectories of parent directories.

Aha ok. I did some googling around and found-out the following that may help:
- The borland make file could use PUSHD and POPD command to change directory.
Unfortunately this will only work on NT based systems.
- When calling the CD or CHDIR command without any parameter it will return the
current path. The problem is then to get the returned value in a borland
macro... As far as I see borland makefiles functionality doesn't allow this, of
course I could be wrong.
- Another dirty workaround would be to output a batch file that does the
following (note: not very well tested!)

guidelib:
    @echo cd ..\.. > %temp%\$<.bat
    @echo $(MAKE) -f makefile.bcc $(MAKEARGS) all >> %temp%\$<.bat
    call %temp%\$<.bat
    @del %temp%\$<.bat

Note that this doesn't require use to cd back to the old dir as call takes care
of that.

BTW. Would it be possible to also foresee a clean rule for the subprojects? I
was thinking of a cleanall or veryclean rule... just so there is a way to do
clean action for all subprojects as well.

Regards,
Hans.








-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn