It is currently Mon Oct 16, 2017 3:13 pm

All times are UTC - 7 hours



Forum rules


Related:



Post new topic Reply to topic  [ 18 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Tue May 31, 2016 4:30 am 
Offline
User avatar

Joined: Sat Jan 03, 2015 5:58 pm
Posts: 367
Location: ...
If you look at the newest version on GitHub, WLA's command line argument parser has been changed to be much closer to *nix style.

This:
Code:
wla-6502 -Dpizza="good" -L../ -vio bla.s bla.o

Has become:
Code:
wla-6502 -D pizza="good" -L ../ -v -i -o bla.o bla.s


The same goes for wlalink.

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.


Top
 Profile  
 
PostPosted: Tue May 31, 2016 9:27 am 
Offline
User avatar

Joined: Sun Jul 01, 2012 6:44 am
Posts: 337
Location: Lion's den :3
Thanks! I'll put up new binaries in a minute. :)

_________________
Some of my projects:
Furry RPG!
Unofficial SNES PowerPak firmware
(See my GitHub profile for more)


Top
 Profile  
 
PostPosted: Tue May 31, 2016 12:01 pm 
Offline

Joined: Tue Oct 06, 2015 10:16 am
Posts: 552
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 :P


Top
 Profile  
 
PostPosted: Tue May 31, 2016 12:16 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3192
Location: Mountain View, CA, USA
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.

Top
 Profile  
 
PostPosted: Tue May 31, 2016 12:22 pm 
Offline
User avatar

Joined: Sat Jan 03, 2015 5:58 pm
Posts: 367
Location: ...
calima wrote:
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 :P

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.

Koitsu beat me to it so there ya go.


Top
 Profile  
 
PostPosted: Tue May 31, 2016 12:33 pm 
Offline
User avatar

Joined: Sat Jan 03, 2015 5:58 pm
Posts: 367
Location: ...
Also, koitsu, WLA will probably figure out that it's reading a binary file as input before opening the actual input file and overwriting it. Can't confirm right now.

EDIT: yep, it looks like the "object file" isn't opened until a later stage than source file parsing.


Top
 Profile  
 
PostPosted: Tue May 31, 2016 5:19 pm 
Offline
User avatar

Joined: Tue Jun 24, 2008 8:38 pm
Posts: 1517
Location: Fukuoka, Japan
@Koitsu

It will be possible in a near future to support files longer than 260 in windows but what kind of mess it will do for older apps is a good question.

http://news.softpedia.com/news/microsoft-removes-260-characters-path-length-limit-in-windows-10-redstone-504596.shtml


Top
 Profile  
 
PostPosted: Tue May 31, 2016 7:59 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19081
Location: NE Indiana, USA (NTSC)
nicklausw wrote:
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.

You could do as koitsu mentioned: include a renamed copy of FreeBSD's implementation of getopt_long.


Top
 Profile  
 
PostPosted: Tue May 31, 2016 11:15 pm 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1338
I've never cared for all the variation on command-line tool arguments, but I can't even come up with a standard that I like myself. There's:

Combining flags into one argument: -cJf
Standalone simple arguments: -c
Simple arguments that take another argument: -o test.o
Longer arguments: -create
Allowing longer arguments and flag combining: -cJf --fomit-frame-pointer -o test.o
Packing arguments: -Dvalue
Packing arguments a bit nicer: -D=value
Packing arguments with longer names: --define=value

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.

Code:
# function unique(source)
unique = \
  $(eval __temp :=) \
  $(strip \
    $(foreach s,$1,$(if $(filter $s,$(__temp)),,$(eval __temp += $s))) \
    $(__temp) \
  )


This works great, except on OS X where they decided to use: "-framework Carbon -framework Cocoa"; and I remove the second -framework.

... it's all a big, inconsistent mess =(


Top
 Profile  
 
PostPosted: Wed Jun 01, 2016 2:22 am 
Offline

Joined: Tue Oct 06, 2015 10:16 am
Posts: 552
As koitsu said, your program appears to be GPL. As such, you're allowed to use gnulib, a portability framework for third-world platforms such as Windows that lack basic infrastructure ;)

gnulib encourages you to copy the relevant stand-alone files to your project. Thus no external dependency, just a platform check if those files are needed.

@byuu

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


Top
 Profile  
 
PostPosted: Wed Jun 01, 2016 2:52 pm 
Offline
User avatar

Joined: Sat Jan 03, 2015 5:58 pm
Posts: 367
Location: ...
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.


Top
 Profile  
 
PostPosted: Wed Jun 01, 2016 3:23 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19081
Location: NE Indiana, USA (NTSC)
Perhaps because UNIX users expect familiar "traditional" argument behavior to be present and become frustrated when it isn't. (See "evil", "rude", and "evil and rude" in the Jargon File.)

Even if getopt.c is big, say "It's vendored, so you don't have to think about it; just use it."


Top
 Profile  
 
PostPosted: Thu Jun 02, 2016 3:59 am 
Offline

Joined: Tue Oct 06, 2015 10:16 am
Posts: 552
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?


Top
 Profile  
 
PostPosted: Thu Jun 02, 2016 4:09 am 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1338
> 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.


Top
 Profile  
 
PostPosted: Thu Jun 02, 2016 5:47 am 
Offline
User avatar

Joined: Sat Jan 03, 2015 5:58 pm
Posts: 367
Location: ...
calima wrote:
Eh, "breaking all user projects" is more than a minor issue to me.

It's one that getopt wouldn't actually help out with, because the args order changed.

Later today I'll see about implementing getopt instead, but if things don't work then...¯\_(ツ)_/¯


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 18 posts ]  Go to page 1, 2  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: Guspaz and 11 guests


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

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group