Ralf, > On Feb 4, 2024, at 2:55 PM, Ralf Quint via Freedos-devel > <freedos-devel@lists.sourceforge.net> wrote: > > On 2/4/2024 11:32 AM, Jerome Shidel via Freedos-devel wrote: >> Hi, >> >>> On Feb 4, 2024, at 2:16 PM, Ralf Quint via Freedos-devel >>> <freedos-devel@lists.sourceforge.net> wrote: >>> >>> On 2/4/2024 10:17 AM, Gregory Pietsch via Freedos-devel wrote: >>>> I made recompiling Edlin easy for non-programmers, so that shouldn't be a >>>> problem. You don't have to know a lick of C to recompile it. >>> Well, part of the problem is that in order to recompile, you need to have >>> the compiler (toolchain) installed, which isn't necessarily easy for a >>> non-programmer. >>> >>> >>> Ralf >> I have occasionally compiled edlin to provide an updated version for FreeDOS. >> >> As compile from source goes, EDLIN is not that bad. If I recall correctly, >> It just needs our Watcom-C to compile. Plus a little knowledge on options >> and such things. >> >> In general, it is extremely cumbersome to acquire all the exact required >> pieces to accomplish. An fairly often after spending a few hours on trying >> to get a successful compile, I will end up giving up. Therefore, I do that >> very rarely anymore for almost anything. > The problem with the whole NLS/i18n thing is that it is not only done with > just translating some text extruded from the sources. And recompiling some > programs which don't lend themselves well to the whole "kitten" shebang. It > would require a lot of testing, which needs to be done by someone with those > native language skills (plus some technical knowledge what it is all about). > A lot of command line tools might be fairly easy to do, but for anything that > is using a more formatted screen output, this also requires to check where > things are "overflowing" (for lack of a better term right now)/misalignment…
Yup. > And we have a very limited number of people that would have ALL the required > skills. Yup. > IMHO, before getting too much wound up with everything that is involved, I > think we need to make sure to have a proper English version, for everything, Yup. >> >> As discussed in the online meeting, it would be nice to include dependency >> requirements in the package metadata. This makes me think we could possibly >> include the build-dependency requirements as well. Plus a per package >> universal build batch. That would be a lot of work and probably require >> frequent updating when packages change. > I see that there would be some effort initially to add that info, but > seriously, how much are dependencies as such changing for any given program > after that? For small projects, not usually much changes or very often. On the other hand for large projects, sometimes different libraries come and go. But generally, the problem with these are based on specific versions of libraries. Or, sub-dependency libraries and their versions. However, I only extremely rarely make the exception and compile projects we distribute from source. So, the problem may not be as bad as I suspect. >> >> But on the other hand, it would be very nice if all programs (excluding >> those made with commercial compilers like Turbo Pascal) could be built from >> source simply by installing the required build packages. >> >> This leads me to think, maybe we should go back to the old days when sources >> were in their own separate package and not included in the binaries package. >> > That was a move that I have never understood in the first place, as the vast > majority of people downloading FreeDOS are likely just interested in getting > it running, rather than doing any development. Specially if things aren't as > simple anymore as they (mostly) used to be in the days of DOS, too many > Linuxisms have crept in, which makes it so much harder for people that are > just trying to get back into DOS and haven't done anything programming wise > for the last 20-30 years, and then in things like BASIC or Turbo Pascal, > which are all "programma non grata" for a lot of OSS license minded folks… Furthermore, if the packages were split back into BIN and SRCS, we could provide the sources on a separate media. This could possibly cut the size of the release media in half. Maybe even alleviate the need for a BonusCD. Possibly just the LiveCD, LegacyCD and a SourcesCD. Change back to the split packages would require some tweaking to the installer and RBE. Probably FDIMPLES as well. Nothing to difficult. The online package repo management software used on ibiblio and fd.lod.bz is not designed for it. But, those places could just keep using the combined packages until I get around to making the next version of the repository management utilities. > Ralf :-) Jerome > _______________________________________________ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > <mailto:Freedos-devel@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/freedos-devel > <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
