For the attention of the packager:

I found a way of using a pascal compiler command to compile the
Lazarus project without having Lazarus running. The procedure is as
follows:

cd to-directory-containing-sources

Issue this weirdo-of-a-command:

fpc-2.6.4 -MObjFPC -Scghi -O1 -Tlinux -g -gl -vewnhi
-Filib/x86_64-linux -Fl/opt/gnome/lib
-Fu/usr/lib/lazarus/1.2.4/lcl/units/x86_64-linux/gtk2
-Fu/usr/lib/lazarus/1.2.4/lcl/units/x86_64-linux
-Fu/usr/lib/lazarus/1.2.4/components/lazutils/lib/x86_64-linux
-Fu/usr/lib/lazarus/1.2.4/packager/units/x86_64-linux -Fu.
-FUlib/x86_64-linux -l -dLCL -dLCLgtk2 netman.lpr

Using this command can allow 'make' to compile all sources without
using the IDE.

Edward

On 25/08/2015, Irrwahn <irrwahn@???> wrote:
> On Tue, 25 Aug 2015 15:24:01 +0100, Rainer Weikusat wrote:
>> Irrwahn <irrwahn@???> writes:
> <snip>
>>> It is totally sensible to break down the character set to something that
>>> is more or less guaranteed to be valid for building names in any file
>>> system currently in use on this planet.
>>
>> This targets Linux with no chance of (and no intention to be) portable
>> to anything else as it's basically a wrapper around a bunch of Linux
>> (and even Debian) commands. There are exactly two bytes/ chars which must
>> not
>> appear in a filename under these circumstances, '\0' and '/'. Anything
>> else is valid. Encoding other non-printable characters makes some sense
>> in case these files are intended to be perused by humans, however, if
>> this is not intended, it can as well be skipped as software doesn't need
>> to 'look' at graphemes to distinguish byte sequences. Blindly extending
>> this to "anything with bit 8 set" means it will replace all non-ASCII
>> characters with "something completely unintelligible to humans" despite
>> the machine still doesn't care. And that's not only the odd 'national
>> characters' which appear in Western European alphabets but potentially,
>> completely independent ones like Greek of Cyrillic.
>
> Well, the POSIX "Fully portable filenames" lists these characters:
> A–Z a–z 0–9 . _ -
> But you are probably right that we can safely assume modern, sane,
> unicode aware, "linuxy" filesystems for the case at hand. That leaves
> us with two reasonable approaches:
>
> A) Only escape '/' and '\0' (and the escape character, of course) and
> leave the rest as-is, making for plain human readable filenames, or
>
> B) Hex (or even base64 :P) encode the whole shebang and not give a hoot
> about readability.
>
> Personally, I'd opt for A. And while at it, treat an SSID as what it is:
> "a sequence of 0 to 32 octets", e.g. pass it around as a buffer with
> associated length information, just as a wireless station does.
>
> I'd go and have a stab at it, if only for the fun of it, but that would
> affect the backend incantations [*]. And since I wrote my last line of
> Pascal in 1987, I'd need Edward's consent and assistance.
>
> [*] Best way would probably be to escape the SSID in the frontend, pass
> the encoded "string" and only decode in the backend where actually needed.
> That way at least the argument handling wouldn't have to change much.
>
> --
> Irrwahn
>
>
>
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>