From f566a9282c22b550925dae47e484e87f155c70f0 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Przemys=C5=82aw=20Czerpak?= Date: Wed, 24 Jun 2015 20:32:30 +0200 Subject: [PATCH] 2015-06-24 20:32 UTC+0200 Przemyslaw Czerpak (druzus/at/poczta.onet.pl) * src/pp/ppcore.c ! fixed directory include precedence in #included files which are not marked as system headers (system headers are enclosed in <>) Now the following order is used: 1) try to access included file as is starting from current directory 2) if included file has relative path then check if the first compiled file has path and if yes try to access file using this path as start point 3) check INCLUDE paths (envvar and -I parameter) Previous version used: 2 for nested files or 1 for first file or when first file was given without path then 3. Now we are Cl*pper compatible but such version strongly depends on current directory which has the highest priority. Personally I do no like such behavior because it may give different results when current directory is changed. --- ChangeLog.txt | 17 +++++++++++++++++ src/pp/ppcore.c | 18 ++++++++++++------ 2 files changed, 29 insertions(+), 6 deletions(-) diff --git a/ChangeLog.txt b/ChangeLog.txt index 0091b37d4e..6d07201163 100644 --- a/ChangeLog.txt +++ b/ChangeLog.txt @@ -10,6 +10,23 @@ * Change, ! Fix, % Optimization, + Addition, - Removal, ; Comment */ +2015-06-24 20:32 UTC+0200 Przemyslaw Czerpak (druzus/at/poczta.onet.pl) + * src/pp/ppcore.c + ! fixed directory include precedence in #included files which + are not marked as system headers (system headers are enclosed in <>) + Now the following order is used: + 1) try to access included file as is starting from current directory + 2) if included file has relative path then check if the first + compiled file has path and if yes try to access file using this + path as start point + 3) check INCLUDE paths (envvar and -I parameter) + Previous version used: 2 for nested files or 1 for first file or when + first file was given without path then 3. + Now we are Cl*pper compatible but such version strongly depends on + current directory which has the highest priority. Personally I do no + like such behavior because it may give different results when current + directory is changed. + 2015-06-24 13:49 UTC+0200 Przemyslaw Czerpak (druzus/at/poczta.onet.pl) * utils/hbmk2/hbmk2.prg ! fix header search algorithm to handle headers specified diff --git a/src/pp/ppcore.c b/src/pp/ppcore.c index 19789a0cc4..afcd769de6 100644 --- a/src/pp/ppcore.c +++ b/src/pp/ppcore.c @@ -1959,7 +1959,11 @@ static PHB_PP_FILE hb_pp_FileNew( PHB_PP_STATE pState, const char * szFileName, pFileName->szExtension = NULL; if( ! fSysFile ) { - if( ! pFileName->szPath || ! pFileName->szPath[ 0 ] ) + file_in = hb_fopen( szFileName, fBinary ? "rb" : "r" ); + if( ! file_in && + ( ! pFileName->szPath || ! pFileName->szPath[ 0 ] || + ( ! pFileName->szDrive && + ! strchr( HB_OS_PATH_DELIM_CHR_LIST, ( HB_UCHAR ) pFileName->szPath[ 0 ] ) ) ) ) { char * szFirstFName = NULL; pFile = pState->pFile; @@ -1972,14 +1976,16 @@ static PHB_PP_FILE hb_pp_FileNew( PHB_PP_STATE pState, const char * szFileName, if( szFirstFName ) { PHB_FNAME pFirstFName = hb_fsFNameSplit( szFirstFName ); - pFileName->szPath = pFirstFName->szPath; - hb_fsFNameMerge( szFileNameBuf, pFileName ); - szFileName = szFileNameBuf; + if( pFirstFName->szPath && pFirstFName->szPath[ 0 ] ) + { + pFileName->szPath = pFirstFName->szPath; + hb_fsFNameMerge( szFileNameBuf, pFileName ); + szFileName = szFileNameBuf; + file_in = hb_fopen( szFileName, fBinary ? "rb" : "r" ); + } hb_xfree( pFirstFName ); } } - - file_in = hb_fopen( szFileName, fBinary ? "rb" : "r" ); if( file_in ) iAction = HB_PP_OPEN_OK; else