If you're not sure how things work now, ask here, on GitHub, or view the program's new help message.

Why did you just break all my projects!?

Because of cleanliness of WLA's code, for one. Although that probably means nothing to users, this will: we're looking to get more selective arguments added to the command line, and the existing code for non-"traditional" flags (-vio meaning traditional) would make things go very crazy very fast. An example would be "--quiet-discard" for wlalink to discard sections but don't alert the user when doing so. This flag can now be added easily!

I've tested the code fairly well, but as stated before, if a problem occurs with the flags to blame then head to GitHub or say something here to report it.

I agree, re: using getopt_long(3). However, I can speculate that the reason getopt_long(3) isn't used is because there's no such native equivalent on Windows. This would force the person into having to obtain a getopt library, and make it compile cleanly with the existing WLA DX build environment. I also (wrongly) assumed there'd be a licensing conflict, because GNU getopt is pure GPL, but as it turns out WLA DX is GPL (v2); an alternate approach would be to use FreeBSD's getopt_long(3) (which does have a couple design differences vs. GNU, but they're documented).

Anyway, it doesn't matter to me either way, because as long as it all gets documented (and the commit history showed it clearly did -- thumbs up!), all is well. I would suggest, however, that "gotchas" be documented between previous builds and that one. People will probably find their projects breaking (and in some cases, it looks like filename argument order changed -- that looks dangerous for people's existing projects, ex. .s files now being overwritten?), so documenting "what" they need to change would be helpful.

Also, one thing: about this commit -- this is potentially wasteful. Be aware that Windows has a 260-byte path limit (that means the entire path, including filename), which means that people with long/deep directory structures (don't forget the aspect of multibyte Unicode!) could be bitten by that linker build test failing. The filenames there are 108 bytes long; why not shorten them to something like 20 bytes? I assume the test is to verify WLA DX works with filenames longer than DOS 8.3, so... Just sayin'.

Last edited by koitsu on Tue May 31, 2016 12:22 pm, edited 1 time in total.

Why didn't you use standard getopt_long? That's native nix style, and it accepts both forms, with or without space, so it wouldn't have broken anything.

I always cringe when people re-implement this particular wheel, it's a huge block of code for little reason

As far as I can tell, getopt_long is a dependency that Windows can't meet without external mess. WLA is supposed to be completely cross platform, and unless getopt_long is not only on Windows but also on Amiga and any other old systems we may want the assembler on, things are staying how they are.

Let's not even get into when arguments are meant to only appear once, but don't. Or when arguments conflict with one another.

I recently noticed that, by using pkg-config --libs on multiple projects, my program link line ends up with a lot of duplicate -lLibraryName entries. So I wrote a "unique" function that removes any arguments that have already appeared once before.

I checked out getopt.c and...really? I mean, sure, the functionality is ideal, but the internal getopt function is such a giant that I don't see the problem with just using a much simpler parser that probably handles things just as well outside of the issue in spacing.

Even taking in account the fact that the arguments are only parsed once during the execution of the program making speed a minor issue, I'm just convinced that the existing parser will make the code look much cleaner. That includes getopt.c.

Eh, "breaking all user projects" is more than a minor issue to me. That the function is complex inside, why would it matter? It's also complex when it's inside the libc, yet you'd use it fine then, no?

> Why would you care about the link line? It does no harm to have it slightly longer.

It's just aesthetically more pleasing is all. There are limits to the maximum length of a command-line execution. I have been told that MAME actually runs into this issue and has to build several library blocks to get the final link phase to work. I'm nowhere near it even at five emulator cores, and kitchen sink style audio/video/input drivers that every API available on each OS for user choice.

Given this issue, I'm probably going to revert that change.

> I checked out getopt.c and...really? I mean, sure, the functionality is ideal, but the internal getopt function is such a giant that I don't see the problem with just using a much simpler parser that probably handles things just as well outside of the issue in spacing.

There's two very distinct classes of programmers in the world.

There's the kind that looks at programming like building with legos. Find all the pieces you want, snap them together! You end up with a very pretty lego statue in a few days. This is the kind that would say "just use getopt.c from another project."

Then there's the kind that wants to learn everything about programming, how everything works, and wants to pare everything down to only what's required and nothing more. People that look for perfection. You end up with masterpieces, but they take you months instead of days to create. This is the kind that would say "write your own argument parser that does only what you want it to do."

There's really nothing wrong with either approach. The big problem is that one side (usually from the former camp, but not always) loves to denigrate the other side. Humans just seem to have a huge issue with accepting that people who disagree with them aren't malicious, crazy, and/or incompetent.

Who is online

Users browsing this forum: No registered users and 5 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum