> On May 28, 2024, at 7:56 PM, Jim Hall via Freedos-devel > <freedos-devel@lists.sourceforge.net> wrote: > > Jim Hall wrote: >> >>> This didn't get any discussion a month ago. Since it didn't appear in >>> T2405, I wanted to raise it again for T2406. Can we add this to T2406? >>> Adding a DJGPP.ENV file is all you need to compile programs with IA-16 >>> GCC without installing the full DJGPP environment. >>> >>> To make it easier to add to the distribution, I've created a 427-byte >>> zip file that contains DJGPP.ENV and SETENV.BAT; if you unzip this at >>> the root dir, then both get installed to \devel\i16gcc. I've copied >>> the zip file to the FreeDOS Files Archive at Ibiblio, here: >>> >>> https://ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/c/gcc-ia16/ >>> I16ENV.ZIP >>> >>> The I16ENV.TXT file is just a brief Readme about it. > > Jerome Shidel wrote: >> >> Wouldn’t it make more sense to just add those files to the >> https://gitlab.com/FreeDOS/devel/i16gcc package? >> >> But, I don’t use it. So, maybe that would be an issue or confusing to users. > > > We can add it to that package, if you think that's better. But I also > wrote this in my original email: > > [..] > :: But because we aren't updating any original IA-16 GCC packages, it > :: keeps things clean at the expense of a little extra "overhead" for the > :: package. But if you're installing a C compiler, you likely can spare > :: the tiny extra space. > > ..so I thought it might be nice not to "pollute" TK Chia's IA-16 GCC > release with these two files. And we already have several other > packages that are part of IA-16 GCC, adding this one didn't seem like > a lot of overhead. > > But ultimately it doesn't matter to me if it gets merged into the > https://gitlab.com/FreeDOS/devel/i16gcc package or stays separate. > > > Jim >
I see what you’re saying about “polluting” the existing package. It also would require additional care anytime the package received an update. Maybe it be possible to convince TK Chai to add the changes in his upstream version? We could always add a small package for it. Then if the upstream version is updated, we could drop the “patch” package. > > _______________________________________________ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
