Well, we discussed this issue at fairly great length at the various
meetings, and every time the answer was "make the build system
faster". I believe we even had a discussion about this very thing
(not being able to build in subdirectories).
This weekend's change should have almost no real affect on the
ability to add/modify/debug anything. Before, if you ran "make" in a
framework, it recursed into the base/ directory, ran make there, then
ran make in the framework directory (which never did anything). It
didn't build any of the components in that framework (it hasn't for a
month or so). Now, if you run "make" in a framework directory, it
just builds the stuff in base without recusing. Of course, you can't
run make in the base/ directory, but since running make in the
framework directory is essentially equivalent, it doesn't exactly
matter.
Brian
On Nov 20, 2005, at 10:04 PM, Ralph H. Castain wrote:
Just as an FYI -- this proposed fix didn't work. It apparently takes
a great deal more to "undo" the Makefile consolidation. I worked on
it for a couple of hours and finally just gave up.
The last commits, of course, only made this situation worse as even
more of the tree now is so heavily integrated that you really can't
work on just one subsystem any more - the whole tree has to be
corrected if you change an API before you can test your changes.
Frankly, it isn't clear to me that we really improved things by all
these changes. We may have made an autogen faster, but we have
definitely made it harder to develop a subsystem. Is that really a
good trade? I wonder.
Ralph
At 08:08 AM 11/15/2005, you wrote:
* Ralph H. Castain wrote on Tue, Nov 15, 2005 at 03:45:26PM CET:
At 07:33 AM 11/15/2005, you wrote:
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.
Your proposed change would help a great deal - thanks! Can you steer
me through the change?
Sure. Make sure to have automake installed, apply the patch below,
then `make' should cause the Makefiles to be rebuilt.
For building/testing, I'd do as above:
cd orte
make dps/libdps.la
To now recreate liborte.la without triggering all other stuff:
If you happen to use GNU make, you could use this hack (warning!
hack! do not ever do this for non-debug builds!)
make -t
This just touches everything, so the next run of make will believe
everything to be up to date. (You need a "make clean" to undo this
when you really want everything updated.)
Then, to recreate liborte, you do
../libtool --mode=clean rm -f liborte.la
make liborte.la
(In most but not all cases, the former can be replaced by "rm -f
liborte.la"). Hope that helps.
Cheers,
Ralf
Index: orte/dps/Makefile.am
===================================================================
--- orte/dps/Makefile.am (revision 8159)
+++ orte/dps/Makefile.am (working copy)
@@ -24,7 +24,8 @@
dps/dps_types.h \
dps/dps_internal.h
-liborte_la_SOURCES += \
+noinst_LTLIBRARIES += dps/libdps.la
+dps_libdps_la_SOURCES = \
dps/dps_internal_functions.c \
dps/dps_load_unload.c \
dps/dps_lookup.c \
Index: orte/Makefile.am
===================================================================
--- orte/Makefile.am (revision 8159)
+++ orte/Makefile.am (working copy)
@@ -33,6 +33,7 @@
lib_LTLIBRARIES = liborte.la
liborte_la_SOURCES =
liborte_la_LIBADD = \
+ dps/libdps.la \
$(MCA_orte_FRAMEWORK_LIBS) \
$(top_ompi_builddir)/opal/libopal.la
liborte_la_DEPENDENCIES = $(liborte_la_LIBADD)
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
