Mail Archives: djgpp/1997/09/14/16:34:39
At 05:09 PM 9/14/97 +0300, you wrote:
<Snipped>
>You didn't run the configur.bat file, did you? It creates the missing
>file, so after you run it, everything works like a charm. (Running
>that batch on Windows 95 requires editing it and its subsidiary batch
>config/msdos/configur.bat.)
No, I hadn't (at that point) run configur.bat, due to the changes needed to
run on Win95/DOS. Later, running everything on DOS 6.22 precluded needing
to change those files at all.
IMHO, it's still an error not to have $(md_file) at that point in the
makefile, though. At the very least, it is inconsistant with all the other
references to $(md_file) file in nearby parts of the makefile.
>
>> Actually, he's right Eli. In cp/Makefile there is this case (please
>> excuse the line-wrap):
>>
>> parse.o : $(PARSE_C) $(CONFIG_H) $(CXX_TREE_H) $(srcdir)/../flags.h
>> lex.h
>> $(CC) -c $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) $(BIG_SWITCHFLAG)\
>> `echo $(PARSE_C)
>> ^^^ ^^^ (Note no trailing backquote)
>
>Nevertheless, it worked for me! I don't have time now to investigate
>this, but if you run configur.bat and then make, it should work for
>you also.
Well, COMMAND.COM complained to me that there was no such file as `echo.
See my earlier message for the fix I used, I think it is cleaner.
>> There may well be more changes to
>> *DJ*'s makefile if using bash, but not to the original GNU version.
>> Which, after all, should be a porter's goal, shouldn't it?
>
>No, I don't think so. The goal should be (IMHO) to make building the
>package as easy as it can get. The easiest build is when you are not
>required to install any packages that you don't already have. This
>means that stock DOS tools and what's in djdev are the only tools you
>should count on.
I understand that opinion, I just do not agree with it. It confuses ease
for the re-builder with ease for *both* the re-builder *and* the originator
of the port. I will restate my earlier opinion that those of us willing to
attempt re-builds should not balk at obtaining all the necessary tools to
perform that re-build. One need not understand the tool to use it. Getting
tools is
secondary in importance, so long as the originator *identifies* all the
tools needed.
>However, it turns out that, for many packages, achieving that goal
>puts an unbearable burden on the person who ports the package.
>Since people who port the package donate their work, they get to
>choose the tools they use to do that.
>
>But that should not, in my view, be taken as the goal. It is a
>compromise between the goal and the hard reality.
Again, I must respectfully disagree. If we wish to attract more help in
porting more packages and make porting new versions easier than past
versions, we need to take advantage of all that has been done so far. We
should build on those who preceded us, not try to replicate their work effort.
And again, I understand your point of view. It is an admirably minimalist
standpoint, which has unquestionable advantages. I believe, however, that
those advantages are far outweighed by the advantages of using all of the
tools we already have to make future porting jobs easier, instead of harder,
and in enlarging the community instead of keeping it smaller.
I also believe there is room for both of our points of view to co-exist.
Porting is not, after all, a competition, but a cooperation.
Respectfully,
Peter
- Raw text -