[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
George Foot <gfoot@xxxxxxxxxx> writes:
> On Thu, Aug 24, 2000 at 08:09:03AM +0700, Michael Bukin wrote:
> > George Foot <gfoot@xxxxxxxxxx> writes:
> >
> > > > http://www.inp.nsk.su/~bukinm/allegro/3933/release.txt
> > >
> > > Hmm, that's a lot to do. :) Was there a problem with just
> > > running `cvs update' then `misc/zipup.sh', then
> > > `misc/mkunixdists.sh'? That's how it's meant to work IIRC -- I
> > > did try to make these things avoid CVS files etc after making
> > > the CVS repository.
> >
> > This will not work because some files which should go into library are
> > not in CVS (configure, makefile.dep, maybe some others). Running
> > autoconf, then configure script and 'make depend' produce some files,
> > which should not be placed to library (config.cache, config.log), but
> > AFAIK, there is no way to clean these with Unix makefile, only
> > together with some files which should go to library.
>
> I've looked into this more, after someone complained on IRC --
> it looks like the djgpp version doesn't work either. I've come
> to the conclusion that the zips don't include the dependency
> information at all! It's impressive that Make gets on as well
> as it does without that information, I think. :) Consequently,
> all the intermediate files (plugins.h, mmx.h, asmdef.inc) have
> to be requested by hand.
Indeed there is a problem with generating dependency by using DJGPP
gcc. Just saying gcc -UDJGPP may not always undefine DJGPP, because
it is also defined by <sys/version.h> which is included by -imacros
option in specs file (only for some versions of DJGPP and gcc).
Preprocessor does not include albecfg.h, (because DJGPP is tested
first), thus ALLEGRO_BEOS is not defined and BEOS specific files could
not pass '#ifndef ALLEGRO_BEOS'. I have removed imacros option from
my specs file (DJGPP is also defined in specs file), I fixed it in CVS
by moving test for __BEOS__ before DJGPP test in alconfig.h.
The same feature affects building asm files for Windows compilers with
DJGPP gcc. Test for DJGPP should be moved after all windows compilers
in src/i386/asmdefs.inc.
I've built WIP3933 on Linux, so this problem did not affectdependency
generation. Also I removed -imacros option from gcc specs long before
building DLLs. I'll put this option back and will try to fix all
problems with builds for different platforms.
There was another problem with zipup.sh that it did not include
directories that contained only CVS. Because DJGPP has a feature that
files with all uppercase are converted to all lower case, so
'find . -name CVS' can not find CVS. Before releasing WIP3933 I've
changed it to '-iname CVS' to ignore case. (IIRC, this DJGPP feature
can also be turned off with FNCASE environment variable).
It seems that Allegro 3.9.33 archives don't have missing directories
or files (I tested DJGPP, MSVC, Mingw and Unix default builds, no
static, debug or profile libraries). But when building files in i386
with DJGPP gcc, it may not include correct asmdef.inc file if there is
-imacros option in gcc specs (CVS version should work).
>
> I went back to the current CVS version, to try out zipup.sh and
> see what went wrong -- but nothing did. It's made an almost
> perfect archive, as far as I can see -- all that I can see
> missing is the mingw32 static directories, which weren't added
> to CVS it seems, and all that I can see extra is the demo data
> file, and a tmpfile.txt in the top directory.
Maybe it is necessary to run 'cvs checkout'? Because I have these
directories in my cvs tree and 'Browse CVS Repository' on sourceforge
also shows these directories with makefile.dep files.
>
> On a sidenote, I'm having some problems requesting old versions
> from CVS -- anything which refers to an old version (like a diff
> -r) gives an error from the server. Does anyone else experience
> this, or have ideas as to what causes it?
I do have problems too. Also when I tried to run 'cvs tag TAG .' in
allegro directory, it did not work, though documentation says that it
will tag all files in current directory recursively.
--
Michael Bukin