-->
Page 1 of 1

Help needed with makefile

PostPosted: Wed Apr 13, 2016 2:36 pm
by luni
I had a look at ESP-HTTPD and it seems to be exactly what I need for my project. (I need a Web-Server with an included Web-Socket Server on the ESP). Since this project it is part of a larger project involving a Windows GUI I try to build libesphttpd under Win10 / VS2015.

After a some adoptions regarding the shell tools the main makefile compiles nicely and generates libesphttpd.a. Unfortunately I got stuck at the next step when it comes to building espfs/mkespfsimage/mkespfsimage. The called makefile seems to be very rudimentary, e.g. it doesn't even define the compiler. Looks like I'm missing something fundamental here...

Code: Select allGZIP_COMPRESSION ?= no
USE_HEATSHRINK ?= yes

CFLAGS=-I../../lib/heatshrink -I../../include -I.. -std=gnu99
ifeq ("$(GZIP_COMPRESSION)","yes")
CFLAGS      += -DESPFS_GZIP
endif

ifeq ("$(USE_HEATSHRINK)","yes")
CFLAGS      += -DESPFS_HEATSHRINK
endif

OBJS=main.o heatshrink_encoder.o
TARGET=mkespfsimage

$(TARGET): $(OBJS)
ifeq ("$(GZIP_COMPRESSION)","yes")
   $(CC) -o $@ $^ -lz
else
   $(CC) -o $@ $^
endif

clean:
   rm -f $(TARGET) $(OBJS)


To be honest I don't quite understand what this is supposed to do anyway? Why does libesphttpd try to build a filesystem? Shouldn't the filesystem be built by the application which uses the lib? Anyway, any help would be very welcome.

Regards
Lutz

Re: Help needed with makefile

PostPosted: Fri Apr 15, 2016 12:21 am
by Sprite_tm
Makefiles don't always need to implicitly declare everything: there's a bunch of implicit rules and settings that are used when not explicitly defined. The C compiler is one of them; normally, $(CC) returns whatever default C compiler the host system has. What this Makefile does is build mkespfsimage, a tool (which is supposed to run on the host PC) that takes a bunch of files and converts them to an espfs file.

Yes, maybe libesphttpd shouldn't be responsible for building the filesystem like that... but integrating it in libesphttpd makes it easier to add functionality like automatic compression etc. If that would be left to the application, adding that would need to be done to every single application.

Re: Help needed with makefile

PostPosted: Fri Apr 15, 2016 7:47 am
by luni
Thanks for your support. I didn't look into the source files and assumed that "mkespfsimage" is part of the firmware.... :?
I meanwhile managed to compile mkespfsimage under Visual Studio (disabled all compression for a quick test). Is there any possibility to check if the generated file is correct?
The last missing step ist o generate libwebpages-espfs.a by
Code: Select alllibwebpages-espfs.a: webpages.espfs
   $(Q) $(OBJCOPY) -I binary -O elf32-xtensa-le -B xtensa --rename-section .data=.irom0.literal \
      webpages.espfs build/webpages.espfs.o.tmp
   $(Q) $(LD) -nostdlib -Wl,-r build/webpages.espfs.o.tmp -o build/webpages.espfs.o -Wl,-T webpages.espfs.ld
   $(Q) $(AR) cru $@ build/webpages.espfs.o

Just out of interest: can you explain what the OBJCOPY part is doing to the file generated by mkespfsimage?

Re: Help needed with makefile

PostPosted: Mon Apr 18, 2016 3:55 am
by Sprite_tm
Sure. The idea of this mode of compilation is that the webpages are linked in with the rest of the binary, in the same way e.g. an array within the C code is linked in to the rest of the program. To do that, we need to convert the binary data to an elf file, so the linker understands what it does. The data also needs to go into the correct section, so thelinker won't try to put it in a section that will end up in RAM. That is what the objcopy does. The LD thing is a hack I put in later: with only the objcopy, the webpage data can end up at an address that's not dividable by four, which trips up the espfs code which is optimized for aligned accesses. The LD converts the file objcopy generates into basically the same file, but aligned to a 4-byte address. Finally, the ar command rolls up the result in a nice static archive, ready to be linked in with the final binary.

There's not really any way to check if the file is correct except compiling the example, flashing it into an ESP8266 and seeing if it works. There used to be some testing code to unpack espfs files, but I think it succumbed to bitrot.