Feature #1008

TheIDE: U++ local installation on POSIX. Remove *.bm files, not just GCC.bm

Added by Sender Ghost over 4 years ago. Updated almost 4 years ago.

Status:ApprovedStart date:03/07/2015
Priority:NormalDue date:
Assignee:Sender Ghost% Done:

100%

Category:IDESpent time:-
Target version:-

Description

There is a possibility to create and use many builder files (*.bm), e.g. inside of /usr/local/share/upp directory, which copied to ${HOME}/.upp/theide (or other directory, based on executable name), on first run.
In case of local installation, the files (and directories) copied from /usr/local/share/upp to ${HOME}/upp and GCC.bm file removed for some reason.
I propose to remove *.bm files inside of ${HOME}/upp directory based on /usr/local/share/upp/*.bm files, not just GCC.bm, in case of local installation.

uppsrc_ide_SrcUpdater_Install.cpp.diff Magnifier - The diff file to apply for uppsrc directory (662 Bytes) Sender Ghost, 03/08/2015 01:22 AM

2_uppsrc_ide_SrcUpdater_Install.cpp.diff Magnifier - The diff file to apply for uppsrc directory (additional) (452 Bytes) Sender Ghost, 03/09/2015 11:01 PM

History

#1 Updated by Sender Ghost over 4 years ago

The topic might be changed to:
TheIDE: U++ local installation on POSIX. Remove *.bm files, not just GCC.bm

#2 Updated by Sender Ghost over 4 years ago

  • File deleted (uppsrc_ide_SrcUpdater_Install.cpp.diff)

#3 Updated by Sender Ghost over 4 years ago

Changed localsrc to globalsrc variable for FindFile.
In this case, the algorithm searches *.bm files inside of /usr/local/share/upp directory (for example) and deletes them inside of ${HOME}/upp, which already replaced, when copied. Other *.bm files are not affected.

#4 Updated by Miroslav Fidler over 4 years ago

  • Assignee changed from Miroslav Fidler to Jan Dolinár

#5 Updated by Sender Ghost over 4 years ago

  • Subject changed from TheIDE: U++ local installation on POSIX to TheIDE: U++ local installation on POSIX. Remove *.bm files, not just GCC.bm
  • Status changed from New to Patch ready

#6 Updated by Jan Dolinár over 4 years ago

I can apply your patch, it should not break anything. On the other hand, it probably won't fix much too, because AFAIK there is only GCC.bm in the packages. And even if there was any other file, it would be a problem if it stayed in the sources directory.

#7 Updated by Jan Dolinár over 4 years ago

  • Status changed from Patch ready to Ready for QA
  • Assignee changed from Jan Dolinár to Sender Ghost

#8 Updated by Sender Ghost over 4 years ago

  • Status changed from Ready for QA to Approved

Thanks.
These changes are proposed for current U++ 8227 release on FreeBSD, for example.
But I think, the user might use own *.bm files also. The proposed patch is a generalized solution of your own algorithm.

#9 Updated by Sender Ghost over 4 years ago

I think, the DeleteFile might be replaced with cross-platform FileDelete function.
Also, while DeleteFile (and FileDelete) uses unlink function on POSIX, which not deletes directories, the ff.IsFile() check might be useful.

I attached the additional patch for current revision.

#10 Updated by Sender Ghost over 4 years ago

  • Status changed from Approved to Patch ready

#11 Updated by Sender Ghost over 4 years ago

I need to note, that in case of "GCC.bm" it was ok to use DeleteFile function, but FindFile::GetName does conversion with FromSystemCharset[W] function, where FileDelete does ToSystemCharset. Therefore, it is appropriate to use ff.GetName() with FileDelete.
There was a need to do this in a first patch. Sorry about that.

#12 Updated by Sender Ghost over 4 years ago

FindFile::GetName does conversion with FromSystemCharset[W] function

It was for PLATFORM_WIN32. In PLATFORM_POSIX it returns name.
But I still think that proposed additional patch might be useful.

#13 Updated by Sender Ghost over 4 years ago

I think, the DeleteFile might be replaced with cross-platform FileDelete function.

Looks like, DeleteFile is cross-platform also, in case of Windows (as WinAPI function) and Posix.
What remains is ff.IsFile() check, because FindFile returns directory entries also.

#14 Updated by Sender Ghost almost 4 years ago

  • Status changed from Patch ready to Approved
  • Assignee changed from Jan Dolinár to Sender Ghost
  • % Done changed from 0 to 100

Also available in: Atom PDF