Re: [AD] make install DEBUGMODE=1 failure

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


> > /include  folders.
> > then i go   make install DEBUGMODE=1 (see below)
> > and i get some error about folder already existing.

Yes, Allegro's build system doesn't handle it too well if the directory 
already exists. I think the solution is to do a make uninstall before 
installing a new version, but it's less than ideal.

> Yes, i have brought this up and i made a makefile patch that will solve 
> the error, but it wont fail on linux with bad permissions. Just as longa 
> s you have the lib files installed and the dlls in your system32 folder, 
> it will be fine.

We should really have a way to solve this for all systems. For Unix 
systems, Sam's solution will work, but it won't work on Windows.
The problem is that failing to create the directory because it already 
exists shouldn't break the buildprocess. 

I *think* the problem can be solved by including dependency rules for the 
directories Allegro tries to install to. In one of my own projects (not 
related to Allegro, but has to work on different flavours of UNIX), I have 
the dependencies

all: dirs

dirs: $(OBJDIR) $(LIBDIR) $(EXEDIR)

$(LIBDIR):
	mkdir $@

$(OBJDIR):
	mkdir $@

$(EXEDIR):
	mkdir $@

where I define LIBDIR, OBJDIR and EXEDIR by rules like

ifdef MINGDIR
   OBJDIR = obj/mingw
   LIBDIR = lib/mingw
   EXEDIR = bin/mingw
else
   ifdef DJGPP
...
   else
     OBJDIR = obj/unix
     LIBDIR = lib/unix
     EXEDIR = bin/unix
   endif
endif

Perhaps a similar idea can be used here? I don't know if this will clash 
with the existing build system in some way... I'm busy packing, so I can't 
check if this would work or not now, but I think it might.

Evert





Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/