I assume that in a source release tarball these two files fit to the doc/help.etx, and that these two files are always correct in the cvs. So you only need to rebuild these two files, if you alter doc/help.etx, and than you want a fresh version of the C source help files.
(yes I know this bug id, but I can't attache files to this, therefore a new one)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Actually I don't bother to update source/help* every time I change something in doc/help.etx. One might consider this sloppy, but it's a development branch, so why bother?
In a release of course, the files must match.
Anyway, I think you should be able to build NEdit without Perl, even if you make cleared before.
(Nope, the other bug is about a make bug, but in Microline/XmL/.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> Oops. That's the reason I don't tackle #1411492 myself: I suck at
> makefiles.
Ok, I can look at this.
> So the only issue remaining I see is: Do we want to protect someone who
> make cleaned in doc/ but has no Perl?
Good question. Maybe add a new clean target, which removes any generated files (including these from the parse.y) and add a check if perl and bison is avaiable.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=119143
Originator: NO
Looks nice, but we want to be able to build NEdit without Perl, so I guess we need a failure mode for that.
(Don't you feel like tackling #1411492?)
Logged In: YES
user_id=122956
Originator: YES
I assume that in a source release tarball these two files fit to the doc/help.etx, and that these two files are always correct in the cvs. So you only need to rebuild these two files, if you alter doc/help.etx, and than you want a fresh version of the C source help files.
(yes I know this bug id, but I can't attache files to this, therefore a new one)
Logged In: YES
user_id=119143
Originator: NO
Actually I don't bother to update source/help* every time I change something in doc/help.etx. One might consider this sloppy, but it's a development branch, so why bother?
In a release of course, the files must match.
Anyway, I think you should be able to build NEdit without Perl, even if you make cleared before.
(Nope, the other bug is about a make bug, but in Microline/XmL/.)
Logged In: YES
user_id=122956
Originator: YES
A make clean will not remove these two files, only a make realclean from the top dir or a make clean inside the doc dir.
Logged In: YES
user_id=119143
Originator: NO
Oops. That's the reason I don't tackle #1411492 myself: I suck at makefiles.
So the only issue remaining I see is: Do we want to protect someone who make cleaned in doc/ but has no Perl?
Logged In: YES
user_id=122956
Originator: YES
> Oops. That's the reason I don't tackle #1411492 myself: I suck at
> makefiles.
Ok, I can look at this.
> So the only issue remaining I see is: Do we want to protect someone who
> make cleaned in doc/ but has no Perl?
Good question. Maybe add a new clean target, which removes any generated files (including these from the parse.y) and add a check if perl and bison is avaiable.
Logged In: YES
user_id=119143
Originator: NO
I wonder what realclean is supposed to do, I see mrproper and distclean most often in other projects.
(Yes, I know enough about makefiles to form an opinion about what realclean does.)
Logged In: YES
user_id=122956
Originator: YES
Yeah, mrproper would be a good name.
BTW: this patch is not 'make parallel'-safe.
Logged In: YES
user_id=119143
Originator: NO
>BTW: this patch is not 'make parallel'-safe.
A shame. Single core CPUs are getting extinct.