XPProEmulation without auto-resolve of dependencies

[jimt]

I am building an XP Pro emulation image with FP2007 using the xpefiles.com
configuration. The directions say to add unresolved dependencies by hand
rather than turning on Auto-resolve Dependencies.

This is quite tedious, as all the tap discovered modules have to be added by
hand. I was wondering if this limitation is still required for the FP2007
version.

It would be easier if TD provided a simple list of the missing modules, but
you have to hover the mouse over each row in the task list and try to
remember the name while you go search for the module in the database.

What sort of grief would I bring on if I let it auto-resolve?

 

[KM]

I am building an XP Pro emulation image with FP2007 using the xpefiles.com
configuration. The directions say to add unresolved dependencies by hand
rather than turning on Auto-resolve Dependencies.

Sorry, that requirement was a legacy coming from the old toolkit versions.
Basically with straight SP1 or SP2 tools if you did the Autoresolving
dependencing on such a huge config like XP Pro Emulation it would kill the
project (you'd start seeing stupid CMI out of memory errors right away
:-( ).

With the tool chain being fixed in FP2007 it is way more stable there now.
You can safely turn on Autoresolve dependencies feature and let TD do the
job. Hopefully you've got enough RAM for the database to cache all the
requests. If you have at least 1G or, better. 2G or RAM the work with big
configs like XPProEmulation becomes easy and fun

Hopefully you're using the latest and greatest version of the XPProEmulation
config posted to www.xpefiles.com (created on RTM'd FP2007 toolkit). Later I
will update the readme.txt file on the component posted there. Thanks for
pointing that documentation bug!

Thanks,
KM

 

[jimt]

Hi KM,

Thanks for confirming that dependency auto-resolve can be enabled for FP2007
toolsets. I only have 700MB of ram; yes it is slow. Yes, I am using the
latest XPProEmulation configuration.

Even so, there are many things to manually resolve. Since I am not familiar
with the modules, it takes a little while to research each one (xpecmd helps
on this to show dependencies). For example "CompactPCI Hot Swap Support"
apparently needs one of these four different computer components:

"Intel NetStructure ZT5531 System Master Processor Board"
"Force Computers CPCI-730"
"Generic CompactPCI CPU Board"
"Motorola CPV 5300/Motorola 5350"

And each of them pulls in the Standard PC component... but my "tap"
component calls for the "ACPI Multiprocessor PC". Fun fun...

I wonder if there would be any advantages to packaging the XP Pro emulation
package as a macro component instead of it's own project(?).

Thanks,

 

[KM]

jimt,

I feel your pain. With not enough RAM it is slow and painful to add
components to the huge config.
The very first version of the XPProEmulation I developed on a slow machine
with only 512M of RAM. But even available RAM wasn't the bottleneck there
but the tools which had that awful memory related bugs. The toolkit in
FP2007 is way better now and it just took Microsoft to modify a few lines of
VB code of TD to fix the issue.

Anyway, my point is that adding more RAM to your dev machine will help you
more than anything else to start working with the big XPe projects on a
different level.


I typically disable "CompactPCI Hot Swap Support" stack (most of my targets
didn't support it anyway) so that it doesn't cause many build errors. Look
at the release notes (readme.txt) of the project to see what components are
disabled by default in that config.

Also, if you want to explore dependencies I encourage you to use
DependecyExplorer and ConfigurationExplorer components from XPeTools
packages on www.xpefiles.com website. Those will allow you to explore
components in XPe database or your own config only with some graphic UI and
helpful search filtering functionality built-in.

There are two possible ways on how to approach the "XPe Emulation macro"
idea you are suggesting below:
- the XPProEmulation is a macro listing *all* the software
components from the database. This way the XPProEmulation dhtml page and
script would be amazingly huge and TD would always "die" trying to load the
component's settings.
- XPProEmulation combines certain groups of components and only
shows options per groups. When the actual build starts the component's
script will add all the components from the defined and selected groups.
This approach is already implemented - original XPProEmulation component
from XPeTools packages mentioned above does that. Also, Microsoft's Generic
Driver Support component also implements the group approach.
But please keep in mind that with this "macro component approach"
you will always spend much time trying to add the required components to
your config on the fly. The beauty of the current XPProEmulation project is
that it has already been done once and you can take an advantage of that by
simple loading the project and adding your platform components only.

Please let me know if there is more things you'd like to enhance in the
XPProEmulation project. I am always open to good ideas

Regards,
KM

 

[jimt]

KM--- I just got a system w/2 GB of RAM, and will move to it asap This
is a very good suggestion.

Regarding the xp pro emul config file, some of the sw components tend to
pull in hw modules that I do not want (example: "CompactPCI Hot Swap
Support" ). I still can't see how this keeps getting pulled into the
configuration, as there is no mention of it in the log. I'll try the tools
you suggested, and another try with the DEPTRACE command in xpcmd.

Do you think the original XPProEmulation, the one with selectable groups,
will work ok with FP2007?

Thanks,

 

[KM]

jimt,

Do you think the original XPProEmulation, the one with selectable groups,
will work ok with FP2007?

It certainly will. In the latest version on www.xpefiles.com there were a
few bugs fixed a few months ago where I moved to FP2007.
Just make sure you understand, there won't be selectable groups on the
component's page. Rather you will see a filter that will allow you to add
components from particular groups.

Regards the "CompactPCI Hot Swap Support". I am not sure what you menat by
"I still can't see how this keeps getting pulled into the configuration". It
must be mentoned in the dependency checker log. Or just disable the
Dependency Auto-resolver in TD and run the dependency check again, you
should be able to see a new error (task) that will tell you what component
is tryung to pull in the "CompactPCI Hot Swap Support".
Or use the earlier mentioned ConfigurationExplorer. It willshow you what
components in your own config depend on the "CompactPCI Hot Swap Support".
(typically it gets pulled by Generic CompactPCI support component)

KM

 

[jimt]

I finally got the dependencies to resolve, but it was strange. I would
delete the "CompactPCI Hot Swap Support" component, and do another
dependency check (with auto-resolve still enabled). The module would
reappear in the design, without any comment in the log saying that it
happened, or why it happened. I may have neglected to click off the "task"
list at the bottom of the window before the recheck. I don't see how that
would matter.

On a lark I tried a few more times and finally it "took". Very odd. Maybe
things will be more repeatable when I have more ram on my dev machine. In
fact I'll try to rebuild again from scratch on that system and see if this
issue reproduces.

Also thanks for confirming the xpetools for fp2007, will try them too. I am
reviewing the readme's now. It looked like xpecmd should also report
dependencies and dependees, but the xpecmd command of deptrace did not seem
accurate. I posted a separate question about that in this ng.

Thanks,