How to speed up build process

[Ben]

Hi,
I am fairly new to PlatBuilder, and I have a question.
Everytime I make changes to the PlatBuilder project, e.g. project.reg,
project.bib, and application project I included with the OS image, I use
Build OS | Build and Sysgen to rebuild the OS image, and it takes an hour; it
becomes basically impractical to do any meaningful debugging. I think I must
be doing something wrong. Can anyone tell me the proper way of building the
OS image? I have the share source code installed. Does that affect the build
process? Thanks,
Scott

[Umesh]

hi,
u could do two steps:
1. say any project change u could build selected project and then makeimg.
make sure ur WINCEREL=1
2. use command prompt.
set WINCEREL=1---> to make sure that whatever u build is copied to release
directory.
go to the target directory and run build -c
and then do makeimg

for platform.bib etc files..just do the changes and copy paste in ur release
directory. and then run makeimage..this will save enough time.
i hope im able to answer ur question.
regards
Umesh Jagga

[Steven]

Hello Jagga:

You are really great! Thanks a lot and I will benefit from it too!
Thanks!

BR,

Steven

11/12/2004 9:25:02 AM

Umesh <Um...@discussions.microsoft.com> wrote in message

<DDA88BB8-8E48-4217...@microsoft.com>

> hi,

> make sure ur WINCEREL=1

> 2. use command prompt.

> directory.

> and then do makeimg

>

> regards

> Umesh Jagga

>

>

> "Ben" wrote:

>

> > Hi,

> > process? Thanks,

> > Scott
--
Composed with Newz Crawler 1.7 http://www.newzcrawler.com/

[Brian Kuebert]

A related newbie question - If I'm changing code in the PUBLIC tree (i.e.
adding more debug messages) is there a quicker way than build and system to
create a new image? I navigated to the directory and issued the build
command which comiled it, and then ran makeimg but my new code was not a
part of the image. I must be missing something. Is there a way to compile
just the module I changed and then re-create an image? I'm working from the
command line.....

Thanks!
-Brian

"Ben" <B...@discussions.microsoft.com> wrote in message
news:3E1C307B-7B7D-4833...@microsoft.com...

[Chuck Zalinski]

The batch file "blddemo" does a lot of things to build a final image. It
also has a number of shortcuts to speed things up.

Simplified overview of what blddemo does
* SYSGEN Phase
This phase builds the CE kernel based on your selected SYSGEN variables and
BSP variables
- Build anything in Private if needed
- Build everything in Public
- Build your BSP under the Platform directory

* Buildrel Phase
- Copies your built files to the _FLATRELEASEDIR

* Makeimg Phase
- Creates the final NK.BIN based on stuff in the _FLATRELEASEDIR and your
IMG flags

*** Tricks to Speed things up ***
blddemo -q
This will skip building the Private directory. Normally, you never
change anything here anyway so you are just wasting time calculating
dependecies.

blddemo -qbsp
This is new in 5.0 and skips both Private and Public and only builds
your BSP platform. This is common when you are developing device drivers
for a BSP and didn't change the features you bring into your OS Design (no
SYSGEN or BSP variable changes)

WINCEREL=1
When you are building something in PUBLIC and then run makeimg, you
won't see the DLL in you Flat Release DIr (FRD) because it wasn't copied
there. The build system only does that in the buildrel phase which you
skipped. By setting WINCEREL=1 you get the DLL copied to the FRD as the
last step

Targeted Builds (5.0 using the IDE for your builds)

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wceosdev5/h
tml/wce50tskrunningtargetedbuild.asp

Skipping makeimg by using Release Directory Modules list
If you are debugging an image already flashed to the device, you can
tell the CE filesystem loader to grab your DLL from your PC (in the FRD)
rather than use the one built inside the NK.BIN. This means you can skip
the makeimg step if your newly-built DLL is in the FRD. To do this, go to
the Menu Target \ Release Directory Modules. This will pop-up a dialog that
lets you add your DLL to the list. Now, when you reboot and debug, your DLL
will come from your FRD and not the one in NK.BIN. Combined with Targeted
Builds, this should speed you up a lot.

[Brian Kuebert]

Thanks for the reply Chuck! After reading this I have a question, though:
is setting WINCEREL=1 equivalent to running buildrel after build?

Using WINCEREL=1 then the process would be (from a directory in the PUBLIC
tree):

build
makeimg

but this would be equivalent to WINCEREL not set and doing:

build
buildrel
makeimg

Just trying to make sure I actually understand what you wrote. :-)

Thanks......
-Brian

"Chuck Zalinski" <cha...@online.microsoft.com> wrote in message
news:5ns1ddPy...@cpmsftngxa10.phx.gbl...

[Dean Ramsier]

wincerel causes the makefile to copy the target to the flat release
directory after the build has been complete. It doesn't cover all the other
files that also get copied to the flat release directory.

So, you always need to do a buildrel at least once. After that, if
wincerel is set you can just build and your changed binaries will end up in
the flat release directory.

--
Dean Ramsier - eMVP

"Brian Kuebert" <bkue...@xtremex3.com> wrote in message
news:uTk99pPy...@TK2MSFTNGP12.phx.gbl...

[Ben]

So much better. Thanks.

[Ben]

This is great. Thanks a lot.

[Steve Maillet (eMVP)]

Don't change things in the PUBLIC folders. ALWAYS clone them into your own
workspace and make localized changes there.

--
Steve Maillet
EmbeddedFusion
www.EmbeddedFusion.com
smaillet at EmbeddedFusion dot com

[Steve Maillet (eMVP)]

Just use the SYSGEN option. Don't do a BUILD and SYSGEN as that is a massive
_DEPTREE enabled build. I highly recommend using the UI customization of PB
to remove the BUILD and SYSGEN menu item entirely.

[John Karlsson]

There's two downsides in making your changes directly in the release folder.
1) You have to move the changes to the [platform]\Files folder later and try
them again.
2) You can't make use of the sysgen filter mechanism (; @CESYSGEN IF
[something]).

When I do a change that may make the two things obove screw things up, I do
this instead:

1) Make the change in [platform]\Files
2) run blddemo norel -qbsp and break it as soon as it starts to scan folders
and link.
3) copy the filtered file from [platform]\cesysgen\files to the release folder
4) do makeimg

It will only take half a minute longer and it will save you the trouble of
verifying after you've moved the changes and better yet: save you the
headache when you forget that you've made changes to files in the release
folder and clobber them with a buildrel.

[Dean Ramsier]

I go one better (IMHO) and delete the cesysgen folder from the BSP. In my
experience it doesn't add value to most users. It works great if the BSP
needs to be built in a number of different configurations, and those
configurations sometimes cause build errors due to missing header files.
The rest of the time it causes grief because it adds another build layer
where files get copied and it's easy to forget.

Most users don't have multiple configurations that need the sysgen
filtering, so removing that step can be a good thing.

--
Dean Ramsier - eMVP

BSQUARE Corporation

"John Karlsson" <JohnKa...@discussions.microsoft.com> wrote in message
news:25E7EA46-E745-495C...@microsoft.com...

[Michel Verhagen (eMVP)]

I use the official PB defined methods to do my building. When you change
something in the registry files the method described below takes less
than 2 minutes.

Here's my when-to-build-what "build shortcut" list:

Change something in Platform Settings: do a makeimg
Change something in a driver in the BSP: Build the driver, do makeimg
Change several things in the BSP: Build the BSP, do makeimg
Change something in the BSP and/or the config files (eg platform.reg):
Build & sysgen the BSP, then Copy Files to RelDir, then Build All
Projects and Makeimg.
Change something in the workspace configuration (add or delete a
component): Sysgen the platform (and sometimes a clean sysgen is needed,
eg when changing from RAM based registry to Hive based Registry).

...and since we can't seem to repeat this enough...

*Never ever* do a build and sysgen on the build menu. Better yet, right
click the menu bar, choose Customize, then click the Build OS menu,
select Build & sysgen and *delete* that option from the build menu.

Hope this helps,

Michel Verhagen, eMVP
EmbeddedFusion
www.EmbeddedFusion.com
mverhagen at embeddedfusion dot com

[Williamson@discussions.microsoft.com Roger Williamson]

Is there some sort of Platform Builder guide and Lexicon. I've been feeling
my way through the dark...

"Michel Verhagen (eMVP)" wrote:

> I use the official PB defined methods to do my building. When you change
> something in the registry files the method described below takes less
> than 2 minutes.
>
> Here's my when-to-build-what "build shortcut" list:
>
> Change something in Platform Settings: do a makeimg
> Change something in a driver in the BSP: Build the driver, do makeimg
> Change several things in the BSP: Build the BSP, do makeimg
> Change something in the BSP and/or the config files (eg platform.reg):
> Build & sysgen the BSP, then Copy Files to RelDir, then Build All
> Projects and Makeimg.
> Change something in the workspace configuration (add or delete a
> component): Sysgen the platform (and sometimes a clean sysgen is needed,
> eg when changing from RAM based registry to Hive based Registry).
>
>

> ....and since we can't seem to repeat this enough...

[Paul G. Tobey [eMVP]]

It comes with help, of course. There is also an electronic training course
on CE5 from Embedded Fusion, www.embeddedfusion.com, I think it is. That
would cover a lot of the details of the build system and give you a mental
framework in which to work. Of course, live training is even better and I
think that several of the Microsoft partners, which you should be able to
find a list of at www.microsoft.com/embedded, have that sort of training
available. You *can* learn it yourself by trying things, figuring out why
it broke, finding the explanations, etc., too. It is not magic.

Paul T.

"Roger Williamson" <Roger Willi...@discussions.microsoft.com> wrote in
message news:8D57655E-8009-426D...@microsoft.com...

[Bruce Eitman [eMVP]]

There is a rather old book about Windows CE that is still quite valuable for
understanding the build process. It is "Building Powerful Platforms with
Platform Builder" by Wilson and Havawala. It is for CE 3.0, but the build
system has not changes a lot since then. The most significant change is the
addition of some batch files that can be automatically run at different
stages of the build process.

The training that Paul suggested is also a good way to learn about the build
system as well as the OS architecture.

The basic building blocks of the build system are:

build
cebuild
nmake
buildrel
makeimg
romimage
fmerge

You should be able to read about them in help.

--
Bruce Eitman (eMVP)
Senior Engineer
beitman AT applieddata DOT net

Applied Data Systems
www.applieddata.net
An ISO 9001:2000 Registered Company
Microsoft WEP Gold-level Member

"Roger Williamson" <Roger Willi...@discussions.microsoft.com> wrote in
message news:8D57655E-8009-426D...@microsoft.com...