It would certainly be nice to have patches, that don't depend of each other, rearranging the .am files would be almost useless for that case, though. There are other files, especially dosbox.cpp, that almost every patch messes with even more, so you'd still have to edit the patches to be able to apply more of them to the same source.

Source files being large, they may accept many independent changes to different sections of code. Not so with .am files, where changed regions often share the same context (via contextual diff).

The am patches are the easiest to fix as they change so little. I doubt the devs would change that just to accommodate patches they don't want to apply in the first place...

Dominus wrote:

The am patches are the easiest to fix as they change so little.

Yet such trivial conflicts sometimes prevent the maintainers of custom builds from incorporating otherwise perfectly compatible patches.

I doubt the devs would change that just to accommodate patches they don't want to apply in the first place...

True, but they could do it as an act of good will for all developers, for it would affect all patches that add new source files, not only the two mentioned. With their permission, I can make such a patch myself. I belive this modification will not harm DOSBox in any way, so there is no compromise or downside.

Yes, a patch for this is the first logical step of course.

I hope you understood that I mean a patch that rewrites all file lists in .am files as one file per line in alphabetical order. Unless it is admitted to the official upstream SVN, it will be useless and even harmful.

Yes, I understand

Good stuff. Looks like i might use your new graphics scaling patch after all Ant.

Serious Callers Only wrote:

Good stuff. Looks like i might use your new graphics scaling patch after all Ant.

Very well then—I hope you have already read my last comment about it in the patch's thread. Thanks.

Ehh, i'll do it, once and if dosbox upstream commits your patch. If we don't encourage this practice upstream it would increase fragmentation even more, between those patches that use the upstream file and those that don't. Then, might as well say 'screw upstream' then and baptize one of the forks and the new 'standard' one, which i don't want to do at all.

It is a bold stance that you take! The current indifferent policy of the core DOSBox developers (God bless them!) regarding patches annoys me as well. I cannot talk about individual patches, because I don't use any except mine, but in general I should expect the following approach:

• May reject the patch at will if it does not improve DOSBox as an emulator of MS-DOS games.
• If the patch has commendable intentions but compromises existing functionality or introduces poorly structured code, set well-defined goals for the patch developer about the correcting of the former and the refactoring of the latter, so that the patch might be untimately accepted.

As to the Pixel-perfect patch, I think that emulation of MS-DOS games without lossless scaling makes no sense. It is noteworthy that people are asking videocard developers to implement pixel-perfect modes: here and here.

If you want something changed then email or PM qbix or harekiet. Don't complain about it on a post on a forum and assume that it will be read.

As for major changes to DOSBox that don't have anything to do with improving DOS game compatibility those are usually introduced in private builds and then released to the public in the next version of DOSBox (yeah yeah I know). Should that change? Mabye, mabye not but that's the way it's been.

I don't know the exact names of the files in the munt patch, but munt and pixel_perfect are pretty close in the alphabet, so your proposal might not work for this specific case that you are proposing it for.

Serious Callers Only wrote:

Ehh, i'll do it, once and if dosbox upstream commits your patch. If we don't encourage this practice upstream it would increase fragmentation even more, between those patches that use the upstream file and those that don't. Then, might as well say 'screw upstream' then and baptize one of the forks and the new 'standard' one, which i don't want to do at all.

Aren't you being a bit extreme here ? We are talking about the easiest editable files of DOSBox, which can be edited without knowing anything about programming in C/C++.

Just to be sure: We're talking about this section of a makefile, right?

1libhardware_a_SOURCES = adlib.cpp dma.cpp gameblaster.cpp hardware.cpp iohandler.cpp joystick.cpp keyboard.cpp \
2                        memory.cpp mixer.cpp pcspeaker.cpp pci_bus.cpp pic.cpp sblaster.cpp tandy_sound.cpp timer.cpp \
3			vga.cpp vga_attr.cpp vga_crtc.cpp vga_dac.cpp vga_draw.cpp vga_gfx.cpp vga_other.cpp \
4			vga_memory.cpp vga_misc.cpp vga_seq.cpp vga_xga.cpp vga_s3.cpp vga_tseng.cpp vga_paradise.cpp \
5			cmos.cpp disney.cpp gus.cpp mpu401.cpp ipx.cpp ipxserver.cpp dbopl.cpp

If so, what would listing them each per line achieve? Still the order and line numbers would change with every patch that affects files in the current directory. As far as i know, you can't just add additional lines at the end of a file using the "patch" utility, but you always have to specify a line number and the number of lines you're changing, right? So, if you're adding multiple patches, you'd run into the same trouble you'd run into now: You wouldn't know which lines to change and you'd still have to adjust every patch to the others applied before it.

It would work a bit better as patch is not as dependent on line number but on "context", what is before and after the patched lines. But as Qbix pointed out, if the patches are adding files too close to each other, patch will fail anyway.
As it is trivial to change how about you (Ant_) take it for a test drive and see if it actually helps or whether multiple patches break it anyway.

@serious callers only: you are blowing this out of proportion. But yeah, no one is stopping you from forking. I know from Exult that you tend to have good ideas and get annoyed by the unwillingness of upstream to apply your patches ...

It's more i don't want to fork. Dosbox ecosystem is in a bad shape with multiple forks already, and i'm not the kind of guy that wants to wade into a c compiler when patches inevitably stop working if they aren't modular.

As a aside, this makefile thing makes me think that if there was a way to collect these sources at compile time instead of being explict on the file (ie something like a dir where those cpp files above would be dumped and 'libhardware_a_SOURCES = hardware/*' ) that this small source of conflict could go away. I'm not sure make allows that or anyone involved is willing to upheave their methodology / update their patches to accommodate others.