* [FFmpeg-devel] Relative paths vs. filenames in #includes for project files. [not found] <1208424935.1763717.1710209234082.ref@mail.yahoo.com> @ 2024-03-12 2:07 ` Allan Cady via ffmpeg-devel 2024-03-12 9:53 ` Andreas Rheinhardt 0 siblings, 1 reply; 2+ messages in thread From: Allan Cady via ffmpeg-devel @ 2024-03-12 2:07 UTC (permalink / raw) To: FFmpeg Development Discussions and Patches; +Cc: Allan Cady To test the patch I've been working on, I wrote a small standalone C program, which I had saved in the project root. The file I'm patching is libavutil/timestamp.h. At first I had duplicated a bunch of definitions out of other include files (e.g. struct AVRational, in libavutil/rational.h) so I could run my test program in isolation, but then I decided to see if I could make it work by including the project headers, especially by including libavutil/timestamp.h. But when I tried to compile and run it that way (I'm using Visual Studio Code with the Code Runner Extension), I got a bunch of errors that it couldn't find several files that timestamp.h depends on. I eventually figured out this was because some of the #includes in various files in libavutil are like this: #include "avutil.h" and others are like this: #include "libavutil/avconfig.h" In both of those cases, both the including and included files are in libavutil. I changed the #includes in two files, by removing the "libavutil/", and then my program compiled. I also tested making the whole project, and it still compiled and ran fine as well. So my question is, would it make sense to remove the path from as many of those #includes as possible, so they are filename-only? Given my limited experience, it seems like it might not be a problem, but I don't understand fully how the project manages source dependencies. Just thought I'd toss this out for comment. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". ^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [FFmpeg-devel] Relative paths vs. filenames in #includes for project files. 2024-03-12 2:07 ` [FFmpeg-devel] Relative paths vs. filenames in #includes for project files Allan Cady via ffmpeg-devel @ 2024-03-12 9:53 ` Andreas Rheinhardt 0 siblings, 0 replies; 2+ messages in thread From: Andreas Rheinhardt @ 2024-03-12 9:53 UTC (permalink / raw) To: ffmpeg-devel Allan Cady via ffmpeg-devel: > To test the patch I've been working on, I wrote a small standalone C program, which I had saved in the project root. The file I'm patching is libavutil/timestamp.h. At first I had duplicated a bunch of definitions out of other include files (e.g. struct AVRational, in libavutil/rational.h) so I could run my test program in isolation, but then I decided to see if I could make it work by including the project headers, especially by including libavutil/timestamp.h. > > But when I tried to compile and run it that way (I'm using Visual Studio Code with the Code Runner Extension), I got a bunch of errors that it couldn't find several files that timestamp.h depends on. I eventually figured out this was because some of the #includes in various files in libavutil are like this: > > #include "avutil.h" > > and others are like this: > > #include "libavutil/avconfig.h" > > In both of those cases, both the including and included files are in libavutil. > > I changed the #includes in two files, by removing the "libavutil/", and then my program compiled. I also tested making the whole project, and it still compiled and ran fine as well. > > So my question is, would it make sense to remove the path from as many of those #includes as possible, so they are filename-only? Given my limited experience, it seems like it might not be a problem, but I don't understand fully how the project manages source dependencies. > > Just thought I'd toss this out for comment. > With an out-of-tree build, there are two libavutil directories: The one containing the source files (.c and .h) and the one for the compiled object files. The latter also contains avconfig.h, because that depends upon the specific configuration and is therefore also not part of the FFmpeg repo. With an in-tree build, there is only one libavutil directory and avconfig.h would be reachable for the headers in libavutil/*.h via a simple '#include "avconfig.h"', but that is not the only supported configuration. It is expected that the parent directory of the lib* source directories as well as the parent directory of the lib* build directories is part of the directories where the compiler searches for ""-includes. Just look at the compilation command for some .o file via "make libavutil/channel_layout.o V=1". It contains "-I. -Isrc/" for out-of-tree builds. - Andreas _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". ^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2024-03-12 9:53 UTC | newest] Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <1208424935.1763717.1710209234082.ref@mail.yahoo.com> 2024-03-12 2:07 ` [FFmpeg-devel] Relative paths vs. filenames in #includes for project files Allan Cady via ffmpeg-devel 2024-03-12 9:53 ` Andreas Rheinhardt
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel This inbox may be cloned and mirrored by anyone: git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \ ffmpegdev@gitmailbox.com public-inbox-index ffmpegdev Example config snippet for mirrors. AGPL code for this site: git clone https://public-inbox.org/public-inbox.git