depend: $(SRC_TARGETS) $(TPIKE_TARGETS)
Should a pike really have to be built to generate the dependencies needed for building the pike that is needed to generate the dep...?
Yes, there's a note about that in README-CVS:
Note about the depend target: Dependencies are typically between *.c files and the *.h files they include. Since many *.c files are generated from other input, the depend target often trigs other targets to generate them. Some of those targets use the pike binary in the build tree, so if you do make depend before pike is first built in a new build tree, you're likely to end up building everything. That can seem like a bit of catch 22, but since the dependency files are only needed to correctly rebuild in an old tree, it's perfectly ok to wait with make depend until you have built Pike once.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-01-03 23:01: Subject: depend
depend: $(SRC_TARGETS) $(TPIKE_TARGETS)
Should a pike really have to be built to generate the dependencies needed for building the pike that is needed to generate the dep...?
/ Mirar
And that's where I got in catch 22, since my dependency files were erranous (included files removed in cvs). It couldn't rebuild TPIKE_TARGETS, so it couldn't recreate the dependency files.
I suggest that the dependency targets needed for TPIKE_TARGETS is differentiated from the ones needed for post_modules (etc?), so that you can rebuild them without a catch 22. The target also seems to contain lots of magic to do that already, but it's obviously never used.
/ Mirar
Previous text:
2003-01-05 20:53: Subject: depend
Yes, there's a note about that in README-CVS:
Note about the depend target: Dependencies are typically between *.c files and the *.h files they include. Since many *.c files are generated from other input, the depend target often trigs other targets to generate them. Some of those targets use the pike binary in the build tree, so if you do make depend before pike is first built in a new build tree, you're likely to end up building everything. That can seem like a bit of catch 22, but since the dependency files are only needed to correctly rebuild in an old tree, it's perfectly ok to wait with make depend until you have built Pike once.
/ Martin Stjernholm, Roxen IS
Make cvsclean to get rid of them. And yes, the tpike stuff is a leftover from before there were cmods etc that need a pike to build the pike core (from cvs). It isn't useful anymore and could be cleaned up.
I don't understand how you think it could be solved. There are many other situations where you get similar brokeness which a simple remake doesn't handle, e.g. when a new module directory is added, or when a module Makefile is incorrectly made by a direct configure so that it loses PIKE_SRC_DIR and BUILD_BASE. The recipe in all these cases is to run a sufficiently thorough clean target or remake from a point sufficiently early in the build process (make force_configure or force_autoconfig).
/ Martin Stjernholm, Roxen IS
Previous text:
2003-01-05 21:40: Subject: depend
And that's where I got in catch 22, since my dependency files were erranous (included files removed in cvs). It couldn't rebuild TPIKE_TARGETS, so it couldn't recreate the dependency files.
I suggest that the dependency targets needed for TPIKE_TARGETS is differentiated from the ones needed for post_modules (etc?), so that you can rebuild them without a catch 22. The target also seems to contain lots of magic to do that already, but it's obviously never used.
/ Mirar
What happens if the dependency on TPIKE_TARGETS is simply removed? All other initial Pike dependencies can be solved by using the system Pike, why not dependency creation?
One way to solve it is to include the dependency files in CVS. That way they will get updated when CVS is updated.
force_autoconfig or force_configure doesn't clear dependencies what I can see? I reran autoconfig and configure (manually) before I got caught in the catch 22.
/ Mirar
Previous text:
2003-01-05 22:38: Subject: depend
Make cvsclean to get rid of them. And yes, the tpike stuff is a leftover from before there were cmods etc that need a pike to build the pike core (from cvs). It isn't useful anymore and could be cleaned up.
I don't understand how you think it could be solved. There are many other situations where you get similar brokeness which a simple remake doesn't handle, e.g. when a new module directory is added, or when a module Makefile is incorrectly made by a direct configure so that it loses PIKE_SRC_DIR and BUILD_BASE. The recipe in all these cases is to run a sufficiently thorough clean target or remake from a point sufficiently early in the build process (make force_configure or force_autoconfig).
/ Martin Stjernholm, Roxen IS
What happens if the dependency on TPIKE_TARGETS is simply removed?
The dependencies file might not be complete then since it could lack complete dependencies for peep_engine.c, case_info.h and treeopt.h.
All other initial Pike dependencies can be solved by using the system Pike, why not dependency creation?
It's only indirectly from the dependency creation. The reliance on tpike is in the old targets for peep_engine.c etc, which as I said have historical reasons.
But I vaguely recall that there could be some situations where the tpike stuff still is useful; in some combination of cross compiling and old "system" pikes or somesuch. I don't remember exactly.
One way to solve it is to include the dependency files in CVS.
Autogenerated files doesn't belong in cvs.
force_autoconfig or force_configure doesn't clear dependencies what I can see?
I mentioned those just as general remedies for problems of this kind. They probably don't work in your particular case since the configure script doesn't zap the dependencies file if it exists. Then it's probably necessary to use the final fallback srcclean, which always should be thorough enough to resolve any problem with bogus autogenerated files.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-01-05 22:47: Subject: depend
What happens if the dependency on TPIKE_TARGETS is simply removed? All other initial Pike dependencies can be solved by using the system Pike, why not dependency creation?
One way to solve it is to include the dependency files in CVS. That way they will get updated when CVS is updated.
force_autoconfig or force_configure doesn't clear dependencies what I can see? I reran autoconfig and configure (manually) before I got caught in the catch 22.
/ Mirar
pike-devel@lists.lysator.liu.se
-
Martin Stjernholm, Roxen IS ＠ Pike developers forum -
Mirar ＠ Pike developers forum