summaryrefslogtreecommitdiffstats
path: root/mpvcore/path.c
Commit message (Collapse)AuthorAgeFilesLines
* configure: uniform the defines to #define HAVE_xxx (0|1)Stefano Pigozzi2013-11-031-1/+1
| | | | | | | | | | | | | | | | | | | | | The configure followed 5 different convetions of defines because the next guy always wanted to introduce a new better way to uniform it[1]. For an hypothetic feature 'hurr' you could have had: * #define HAVE_HURR 1 / #undef HAVE_DURR * #define HAVE_HURR / #undef HAVE_DURR * #define CONFIG_HURR 1 / #undef CONFIG_DURR * #define HAVE_HURR 1 / #define HAVE_DURR 0 * #define CONFIG_HURR 1 / #define CONFIG_DURR 0 All is now uniform and uses: * #define HAVE_HURR 1 * #define HAVE_DURR 0 We like definining to 0 as opposed to `undef` bcause it can help spot typos and is very helpful when doing big reorganizations in the code. [1]: http://xkcd.com/927/ related
* Split mplayer.cwm42013-10-301-0/+12
| | | | | | | | | | | | | | | | | | | | mplayer.c was a bit too big. Split it into multiple files. I hope the way it's split makes sense. Maybe some things don't make too much sense, or go against intuition. These will fixed as soon as I notice them. Some files are a bit questionable (misc.c, osd.c, configfiles.c), and suggestions how to organize this better are welcome. Regressions are possible due to reorganized include statements. Obviously I didn't just copy mplayer.c's orgy of include statements, but recreated them for each file. It's easily possible that there are oversights and mistakes, which will show up on other platforms. There is one actual change: the public avutil.h include is removed from encode.h, and I tried to replace most FFMIN/FFMAX/av_clip uses. I consider using libavutil too much as dangerous, because the set of include files they recursively pull in is rather arbitrary and is different between FFmpeg and Libav.
* macosx: move bundle path stuff to path-macosx.mStefano Pigozzi2013-09-181-6/+1
| | | | This makes the code uniform to how stuff was handled for Windows in 1cb55ceb.
* path, win32: redo user configfile path handlingwm42013-09-181-70/+15
| | | | | | | | | | | | | | | | | Remove the ifdef hell from mp_find_user_config_file(). Move the win32 specific code (for MinGW and Cygwin) to path-win.c. The behavior should be about the same, but I can't be sure due to lack of testing and because the old path.c code was hard to follow. (I expect those who care about windows will fix things, should issues pop up - sorry.) One difference is that the new code will always force MPV_HOME. It looks like the old code preferred the mpv config dir in the exe dir if it exists. Also, make sure MP_PATH_MAX has enough space, even if the equivalent wchar_t string is not 0-terminated with PATH_MAX (because apparently the winapi doesn't require this). (Actually, maybe we should just kill all uses of PATH_MAX/MP_PATH_MAX.)
* path: fix undefined behaviorwm42013-09-181-2/+2
| | | | | | | The homepath variable was static, and its value was set to a stack buffer. This means a second invocation of the function would trigger undefined behavior. Moreover the stack buffer always went out of scope before homepath was used.
* macosx: always active bundle path lookup if cocoa is activeStefano Pigozzi2013-09-121-2/+2
| | | | | This is not really something you want to disable anyway. If there is no bundle the code already does it's falbacks anyway.
* mpvcore/path: Fix non-MinGW buildsMartin Herkt2013-09-121-2/+5
| | | | Well that was dumb.
* mpvcore/path: Fix config path handling on WindowsMartin Herkt2013-09-121-5/+21
| | | | | | | | | | | | | | | | | | | | | | | | Previously, mpv incorrectly used the %HOME% environment variable on MinGW to determine the current user’s home directory. This is wrong; the correct variable to use would be %HOMEPATH%, which would however still be wrong since application data goes into the application data directory, not the user’s home. This patch makes it use the local AppData path instead of reading an environment variable. This however exposed another problem (which also affected users who actually had the %HOME% variable set): b2c2fe7a3782 (discussed in issue #95) introduced some changes that make mpv load user config files from the executable path on Windows. The problem with this change is that config_dir was still declared static, so once a config file had been found in the executable path, it would set config_dir to an empty string, so mpv would dump e.g. watch_later data straight into the user’s home. This commit also fixes that. One side effect of this is that mpv no longer considers the “mpv” subdirectory in the executable path (that behavior resulted from the homedir variable always being empty), unless it is somehow unable to determine the local AppData path.
* path: better check for mp_is_url()wm42013-09-041-3/+11
| | | | | | | | | | | The previous check just searched for a "://" substring. This was quite bad, because "://" can be a valid part of a path. Later, I added special handling for filenames starting with "." and "/", so that you could reliably pass arbitrary filenames to mpv, no matter how messed up they were. Even though it doesn't really matter in practise anymore, this is still crap, so add a more reliable check instead.
* path: add a common mp_is_url() functionwm42013-09-041-0/+8
| | | | Remove the duplicated code.
* core: move contents to mpvcore (2/2)Stefano Pigozzi2013-08-061-2/+2
| | | | Followup commit. Fixes all the files references.
* core: move contents to mpvcore (1/2)Stefano Pigozzi2013-08-061-0/+229
core is used in many unix systems for core dumps. For that reason some tools work under the assumption that the file is indeed a core dump (for example autoconf does this). This commit just renames the files. The following one will change all the includes to fix compilation. This is done this way because git has a easier time tracing file changes if there is a pure rename commit.
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-05 14:43:44 +0000