[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On Sat, Aug 26, 2000 at 11:50:40AM +0700, Michael Bukin wrote:
> 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.
Perhaps it would be best if we don't rely on undefining and
redefining things at all. Instead of writing this:
#ifdef DJGPP
we can write:
#if (defined DJGPP && !defined SCAN_DEPEND) || defined SCAN_DEPEND_DJGPP
I may have got the use of `SCAN_DEPEND' wrong here. The idea is
that now we don't have to undefine the default defines, or
define fake ones. It just makes it check SCAN_DEPEND_* instead,
if it's scanning dependencies.
It's a bit messier, but maybe it would solve that problem.
Another alternative is to never use the platform defines at all,
and just use ALLEGRO_DJGPP etc. This would need to be moved out
of aldjgpp.h, albcc32.h, etc because those can't be included in
assembly source. I think it's simpler to just do what I said
above; it would only be needed in aldjgpp.h etc for the C code,
since any C code checking the platform should already use
ALLEGRO_DJPPP etc. The mess would have to be repeated in the
assembly code, though.
> 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.
I thought that the various platforms didn't try to make the
dependencies themselves, when they build, because we can't rely
on them having sed. I don't see how this problem could cause
missing makefile.dep files, and (worse) the object directories
that contain them. If I see the person who had trouble with the
djgpp build, I'll try to find out what happened.
> 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).
Does that mean there are no more problems with zipup.sh? It
really is much easier to just run fixver.sh, then zipup.sh, then
mkunixdists.sh.
> > 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.
Oh yes, oops. `cvs update' doesn't create new directories,
unless you feed it a switch. When I manually created the
directories, and did a `cvs add', the next `cvs update' filled
in the makefile.dep files too.
I'm not sure whether the makefile.dep files should be in the
repository or not. They are generated files, but they're not
going to change much. Part of the problem of putting generated
files in, though, is that cvs uses timestamps on the client as
the primary way to determine whether a file has changed. This
means that whenever you do an update, even if the file has not
actually changed, the client has to get a new copy from the
server to make sure.
On the other hand, they're not going to get modified unless
people actually run the scripts to create them for the various
platforms. But, then again, if they don't get kept up-to-date,
they're useless. :)
I think, overall, we should keep them in and let them always be
whatever was created by the last WIP. Then they have some
meaning, even if they're not totally up-to-date. The .def files
are another issue. We should keep those in too, but if they get
out of date I think it's more of a problem, in Windows anyway.
Still, that will only happen if the content of the DLL changes
dramatically, and it will be fixed each time a new WIP is
released.
George
--
Random project update:
22/06/2000: AllegroGL documentation: http://allegrogl.sourceforge.net/
See under `Documentation' for the AllegroGL Reference Manual in
various formats.