On Monday 15 Mar 2004 1:09 pm, Simon Marlow wrote:
The ghc users guide contains this helpful advice about split-objs..
"don't use it unless you know what you're doing!"
OK, I admit I don't know what I'm doing. But despite this handicap I would like to use split-objs to build a library. I've already discovered it doesn't work with --make, so I guess I have to use a makefile.
Are there any other gotchas waiting for me? Anything else I need to know?
You'll probably need special Makefile rules to handle it too. I think you need to make the subdirectory for the objects (M_split/) beforehand, and touch the object file M.o afterward (so that make dependencies still work).
Thanks, I'm not sure exactly what you had in mind, but I ended up with a rule like this.. HC_OPTS = -Wall -O -split-objs -no-recomp -i$(PKGDIR) -hidir $(PKGDIR) -odir $(ODIR) #How to build (real & dummy) %.o files $(ODIR)/%.o: %.hs @echo Compiling: $< @rm -f $(ODIR)/$(*F)__*.o # Delete the old split objects @$(HC) -c $(HC_OPTS) $< # Create the new split objects @touch $@ # Create/Update the dummy object There seem to be 2 gotchas.. 1- -split-objs has no effect when creating dependencies using the -M option The resulting *.o targets will not be created when actually compiling, (instead you get lots of *__*.o files) 2- These *__*.o files are not placed in the directories one would expect from hierarchical modules. They all get placed in the root -odir. To get around this the above rule uses touch to create a dummy object file in the place where the real object file would be placed if -split-objs had not been used. This seems to make the dependencies generated using -M option work OK. I guess this must be what you meant (something like it anyway:-). Regards -- Adrian Hey