path: root/codepage/Makefile
Commit message (Collapse)AuthorAgeFilesLines
* build: sort sources to build in a more deterministic wayPhilippe Coval2015-01-051-1/+1
| | | | | | | | | | | | | | | | | It has been observed that binaries contents are depending on the order of linked objects. This order is caused by GNU make's wildcard function and the position of sources on filesystem. This change tries to prevent this kind of randomness. Also consider building using -j1 flag to make it even more reproductible. Change-Id: Ie8eee7f336e6f1fa2863c4150d967afd15519f1d Bug: http://bugzilla.syslinux.org/show_bug.cgi?id=57#related Signed-off-by: Philippe Coval <philippe.coval at open.eurogiciel.org>
* Add per-firmware object directory supportMatt Fleming2012-10-161-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now that we have multiple firmware backends it no longer makes sense to write object files to the same directory as their source. A better solution is to write the object files to a per-firmware directory under a top-level object directory. The top-level object directory can be specified on the command-line with the O= variable, e.g. make O=/tmp/obj. If no top-level object directory is specified an 'obj' directory is created in the top-level of the Syslinux source repository. All the existing make targets continue to work as before, however now they apply to all firmware backends, e.g. 'make installer' will build the BIOS, 32-bit EFI and 64-bit EFI installers and place them under $(OBJ)/bios, $(OBJ)/efi32 and $(OBJ)/efi64 respectively. Note unlike every other bit of Syslinux, the gpxe objects are still kept in the src directory, e.g. gpxe/src, since gpxe is only required by the BIOS backend. It is possible to specify a make target for a specific firmware or list of firmware with the following syntax, make [firmware[,firmware]] [target[,target]] To clean the object directory for just the BIOS firmware type, 'make bios clean' To build both the 32-bit and 64-bit EFI installers type, 'make efi32 efi64 installer' Since the Syslinux make infrastructure is now more complex a new file doc/building.txt has been created to explain how to build Syslinux. The top-level Makefile now exports some make variables for use in module Makefiles, - topdir - the top-level source directory of the Syslinux repository, e.g. /usr/src/syslinux - objdir - the top-level object directory for the firmware backend currently being built, e.g. /obj/syslinux/bios - SRC - the source directory in the Syslinux repository for the module currently being built, e.g. /usr/src/syslinux/com32/libupload - OBJ - the object directory for the module currently being built, e.g. /obj/syslinux/bios/com32/libupload Since we're rewriting the Makefile infrastructure anyway it seemed like a good idea to add parallel support. By writing subdirectories as prequisites for make targets the objects in those subdirectories can be built in parallel. Signed-off-by: Matt Fleming <matt.fleming@intel.com>
* Add more codepage data; support disjoint mappingsH. Peter Anvin2008-06-251-1/+3
| | | | | | | Add additional codepage data from the Unicode Consortium. Additionally, add support for generating codepage files for the case where the filesystem codepage and the display codepage do not match. The standard Makefile doesn't actually do that, however.
* FAT: make all codepage data derived from the same placeH. Peter Anvin2008-06-091-4/+4
| | | | | Make the codepage data all derive from the Unicode tables, and create files that could be dynamically loaded in the future.
* FAT: Support VFAT long filenamessyslinux-3.70-pre13H. Peter Anvin2008-06-061-5/+5
| | | | | | | Initial support for VFAT long filenames; currently hard-coded to codepage 865, no support for other codepages or for accessing files with names which aren't in the current codepage. This hopefully shouldn't be an issue for SYSLINUX applications.
* codepage: add "make spotless" targetH. Peter Anvin2008-06-051-0/+2
* Add support for creating codepage/Unicode mapping tablesH. Peter Anvin2008-06-051-0/+17
Add support for creating codepage/Unicode mapping tables; this is a step toward VFAT long filename support.