Your proposed change would help a great deal - thanks! Can you steer
me through the change?
At 07:33 AM 11/15/2005, you wrote:
>* Ralph H. Castain wrote on Tue, Nov 15, 2005 at 03:12:38PM CET:
> > While I generally find the new build methodology (i.e., reducing the
> > number of makefiles) has little impact on me, I have now encountered
> > one problem that causes a significant difficulty. In trying to work
> > on a revised data packing system for the orte part of the branch, I
> > now find that I cannot compile and debug the dps *until* I have
> > completely revised all the rest of the system that uses it. In other
> > words, having made a change to the dps, I first have to go through
> > every function that uses it and make the tree conform BEFORE I can
> > even begin to debug and test the revisions in the dps itself.
>Would it help if only the change not to build a convenience archive in
>orte/dps would be reverted? You could then
> cd orte
> make dps/libdps.la
>and would only have to issue the link command for liborte.la manually
>(to override rebuilding all other files that depend on dps.h). This
>change has very little impact on overall autogen/build execution time.
> > The problem this creates is that - unless I am absolutely correct in
> > my first iteration on the changes - I find myself repeatedly going
> > through the tree, modifying the API calls into the dps, getting
> > everything to compile, then trying the dps, .....discovering that I
> > need to make a change, going through the entire tree to modify
> > everything again, trying the change,.....
>Hmm. For one you are seeing the effect of what is actually a more
>precise representation of the dependencies; though I agree that during
>development this can hurt.
> > Perhaps an option to create a local makefile would help? Not sure if
> > that is possible, but it sure would ease my pain!
>Hmm. May be possible with some hackery, but if above would work well
>enough for you, it'd be much easier.
>Thanks for the feedback by the way, I hadn't thought of this.
>devel mailing list