Re: [Pasdoc-main] Once again, pasdoc 0.9.0 release

[Michalis K. <mk...@po...>]

Carl Eric Codere wrote:
> Quoting Michalis Kamburelis <mk...@po...>:
> 
>> Hi
>>
>> Various things:
>>
>> I created a page in wiki about how I imagine making a pasdoc release:
>> [http://pasdoc.sipsolutions.net/ReleaseMaking]. When I'll get permission
>> to do pasdoc 0.9.0 file releases, this documents exactly what I'm going
>> to do for the targets that I will be handling.
>>
> 
> Ok you can do the Win32 target, but I'll be waiting for your answer on the
> makefiles to see what you think about it... I did some small updates to the
> makefile, that i have commited.
> 
> Makefile update:
> 
>> Long answer:
>>
>> I think that the only clean approach to really merge Makefile and 
>> build-fpc.sh script would be to drop build-fpc.sh script and modify 
>> Makefile to allow everyone to use it.
>>
> 
> Yes, there should no longer be any batch file and any shell script to 
> compile
> apsdoc, at least the console version.
> 
>> why clean target uses "del" command, that is only Win32/Dos specific ? 
>> I would be rather after using Unix-specific commands and relying on 
>> Cygwin and djgpp to make possible using commands like `rm" on non-unix 
>> oses.
> 
> 
> I updated it a bit to try to remove references to DOS specific stuff, 
> actually
> this is a makefile used to create my personal projects that i simply 
> quickly
> modified to be able to compile pasdoc... Also, cygwin is a nono - it 
> gives a
> lot of application compatibility problems, I don't want the makefile to 
> support
> it, I'm ok with using UNIX like commands but in a standard windows 
> console (with
> mingw for example)...
> 

Sure, I didn't mean using Cygwin tools to link pasdoc binaries, or 
relying on existence of / root directory. What I meant was using Cygwin 
tools like `rm' instead of `del'. You can run all Cygwin programs from a 
standard Windows console, so I don't understand this concern...

Anyway, my idea is to use Cygwin tools in such way that you will also be 
able to use MinGW tools without problems.

>> Also default PATHSEP should be /, and Cygwin/djgpp should allow to use 
>> this even on Win32/Dos (not to mention that for native Win32  "/" is 
>> also valid path separator).
> 
> 
> I did not know this, the goal here is to make sure that pasdoc shall still
> compile with DCC. As i said the makefile is there to test compilation for
> different compilers, as well as to create a release package easily with a
> specific command.
> 
>> Also default values of many variables are not generally useful. Not 
>> only paths to most fpc binaries, but also things like BINDIR and 
>> OUTDIR. I believe that default invocation of `make" (without 
>> overriding any make variables) should not pass any -FE or -FU commands 
>> to fpc.
>>
> 
> The paths for FPC binaries are a necessity, especially if you use different
> compiler binaries, I don't see how you would go about it otherwise? It 
> is not
> my idea of putting all those directories in my path.. For me, each user 
> before
> using the makefile should update these configuration files.... no?
> 

Exactly: *no*. This is unbreakable rule for me: when user downloads 
pasdoc sources from CVS, he must be able to compile pasdoc with simple 
execution of `make'. We can assume that fpc is available on $PATH, in 
case it's Win32 we can assume that user already has Cygwin or MinGW 
tools available, we can assume that user uses GNU `make'... But we can't 
expect user to do something specific to pasdoc (like browsing and 
modifying the Makefile, or passing some command-line option to Makefile 
overriding some variable). User must be able to compile with simple 
`make' command.

Ability to compile with various compilers and compiler versions is sure 
a good thing, and it should be available. Sure, if you want to use 
different compilers and compiler versions then it's nice to use 
different output directory for each target (although it's not really 
necessary). I agree with you here. However, your Makefile always sets 
BINDIR to bin and OUTDIR to lib, so actually it doesn't help me if I 
really have various compilers for various targets etc.

Anyway, the ability to use various compilers/targets etc. *must not* 
disallow user to compile pasdoc with simple `make' command (*without 
creating any directories first and without modifying the Makefile*). So 
default compilation should either not use any specific -FE and -FU, or 
it should make sure that given directories exist.

>> you agree with the point that it should be rather Unix-oriented and 
>> rely on things like Cygwin to provide Unix-like environment on 
>> non-Unix OSes. Also default values of variables must be a little more 
>> "neutral", usable to everyone, which means that you would probably 
>> have to override some
> 
> 
> So if i need to make a release, i would have to create a batch file to 
> call the
> makefile with the different paths and targets? For me, I tried to make
> it as
> simple as possible to create a release with a simple command... I don't
> disagree that you can hack through the makefile, but the goal should be as
> simple as possible for everyone to use it without knowledge of all unix
> stuff... But you can hack away though.
> 

Indeed, compiling pasdoc and even archiving a release should be as 
simple as it can be for everyone, and it should not require the 
knowledge of "all unix stuff". This is also my goal.

However, what I see now, is that now using this Makefile to compile or 
archive a release is very troublesome for anyone except you. And for 
people that are not under DOS/Win32, like me, archiving a release using 
this Makefile is impossible.

- everyone must look into the Makefile, make sure that BINDIR and OUTDIR 
are set to proper values and do exist.
- makepkg relies on using bat files (so DOS/Win32 only), and it uses 
rmcvsdir command (which everyone has to compile themselves from FPC 
sources, it's not provided in compiled FPC binaries; anyway, it should 
be changed to trivial use of `find').
- -U..\common\src\delphi for Delphi compilation seems to be something 
specific for your private needs...

If you will have private needs, e.g. you must always specify some option 
when calling dcc or something like that, then yes, you should always 
call `make' overriding some variables at command-line. Probably you will 
have to create some script file to do it. Alternatively, you could just 
keep some local modifications to your Makefile uncommitted, but this is 
of course bad. The rule is simple: you will have to do some work 
privately and make private script for yourself if you really will have 
some private needs (but I don't say that it will be necessity...), but 
the usual users and developers will be able to use this Makefile. As it 
is now, it is on the contrary: the Makefile is probably usable 
out-of-the-box for you, but everyone else must do some adjustments 
inside to really use it.

I'll hack some things inside this Makefile today, see CVS logs to know 
what and why I changed there. Hopefully, it's not unlikely that you will 
actually do not have to make any private script and the resulting 
Makefile will be also still usable out-of-the-box for you.

> Also, contnrs.pas does not exist, what is it? I used version 1.9 to 
> compile and
> the unit does not exist... ??
> 
> 

Strange... exactly what 1.9 version you used ? Contnrs unit is part of 
FPC 1.0.10, 1.9.4, 1.9,6, 1.9.8 and 2.0.0. As far as I can remember it 
existed in all FPC 1.9.x versions, including CVS states. It's part of FCL.

Michalis