Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Don't hardcode install paths #1

Closed
uartie opened this issue Dec 1, 2017 · 1 comment
Closed

Don't hardcode install paths #1

uartie opened this issue Dec 1, 2017 · 1 comment

Comments

@uartie
Copy link
Contributor

uartie commented Dec 1, 2017 •
edited
Loading

Currently, various cmake install targets are installed into hardcoded paths that only follow Ubuntu's directory layout. This burdens developers and packagers on other Linux distros and also makes it impossible to override install destination/prefix. Often, developers prefer to isolate installs into custom locations for various reasons, too.

Instead of hardcoded paths, the install targets should use the GNU standard installation directories. This allows for developers to override specific install paths (e.g. -DCMAKE_INSTALL_LIBDIR=<somedir>). Also, the developer could set -DCMAKE_INSTALL_PREFIX=<somedir> to customize the prefix for all target types.

https://cmake.org/cmake/help/v3.5/module/GNUInstallDirs.html
uartie added a commit to uartie/media-driver that referenced this issue Dec 1, 2017
@uartie
cmake: do not use hard-coded install paths
d2d4960 
Use GNUInstallDirs to determine where to install
artifacts.

Fixes intel#1

Signed-off-by: U. Artie Eoff <[email protected]>
@uartie uartie mentioned this issue Dec 1, 2017
Merged
@oliver-sang
Copy link
Contributor

thanks for reporting this issue and thanks for the PR. I ran into some problem while trying your PR which I added comments in PR. Could you help? Thanks

uartie added a commit to uartie/media-driver that referenced this issue Dec 4, 2017
@uartie
cmake: do not use hard-coded install paths
0d41f0d 
Use GNUInstallDirs to determine where to install
artifacts.

Fixes intel#1

Signed-off-by: U. Artie Eoff <[email protected]>
uartie added a commit to uartie/media-driver that referenced this issue Dec 4, 2017
@uartie
cmake: do not use hard-coded install paths
1861077 
Use GNUInstallDirs to determine where to install
artifacts.

Fixes intel#1

Signed-off-by: U. Artie Eoff <[email protected]>
uartie added a commit to uartie/media-driver that referenced this issue Dec 7, 2017
@uartie
cmake: do not use hard-coded install paths
77cd59f 
Use GNUInstallDirs to determine where to install
artifacts.

Fixes intel#1

Signed-off-by: U. Artie Eoff <[email protected]>
@lakulako lakulako mentioned this issue Mar 22, 2018
Closed
@xhaihao xhaihao mentioned this issue Apr 18, 2018
Closed
@dbabokin dbabokin mentioned this issue Jun 22, 2018
Open
@emmaqiaogn emmaqiaogn mentioned this issue Sep 26, 2018
Closed
@feiwan1 feiwan1 mentioned this issue Oct 16, 2018
Closed
maksenox added a commit to maksenox/media-driver that referenced this issue Apr 24, 2019
@maksenox
[Decode] Prevent mt read/write conflict
3d3753b 
Two concurrent DdiMedia_SyncSurface function calls read and
write the same data when the second frame uses the first frame
as a reference frame.
Enqueue frames order:
  Frame #0
  Frame intel#1 (uses #0 as a reference)
Threads release order:
  Thread intel#1 (waits for Frame intel#1)
  Thread #0 (waits for Frame #0)
Resolution is lock with the mutex the problem source code
(read and update StatusReport), so only one thread writes
the data, the second thread is waiting.
@maksenox maksenox mentioned this issue Apr 26, 2019
Merged
maksenox added a commit to maksenox/media-driver that referenced this issue Apr 30, 2019
@maksenox
[Decode] Prevent mt read/write conflict
0f5cc93 
Two concurrent DdiMedia_SyncSurface function calls read and
write the same data when the second frame uses the first frame
as a reference frame.
Enqueue frames order:
  Frame #0
  Frame intel#1 (uses #0 as a reference)
Threads release order:
  Thread intel#1 (waits for Frame intel#1)
  Thread #0 (waits for Frame #0)
Resolution is lock with the mutex the problem source code
(read and update StatusReport), so only one thread writes
the data, the second thread is waiting.
maksenox added a commit to maksenox/media-driver that referenced this issue May 8, 2019
@maksenox
[Decode] Prevent mt read/write conflict
807b404 
Two concurrent DdiMedia_SyncSurface function calls read and
write the same data when the second frame uses the first frame
as a reference frame.
Enqueue frames order:
  Frame #0
  Frame intel#1 (uses #0 as a reference)
Threads release order:
  Thread intel#1 (waits for Frame intel#1)
  Thread #0 (waits for Frame #0)
Resolution is lock with the mutex the problem source code
(read and update StatusReport), so only one thread writes
the data, the second thread is waiting.
intel-mediadev pushed a commit that referenced this issue May 27, 2019
@maksenox @intel-mediadev
[Decode] Prevent mt read/write conflict
cecbed7 
Two concurrent DdiMedia_SyncSurface function calls read and
write the same data when the second frame uses the first frame
as a reference frame.
Enqueue frames order:
  Frame #0
  Frame #1 (uses #0 as a reference)
Threads release order:
  Thread #1 (waits for Frame #1)
  Thread #0 (waits for Frame #0)
Resolution is lock with the mutex the problem source code
(read and update StatusReport), so only one thread writes
the data, the second thread is waiting.
intel-mediadev pushed a commit that referenced this issue Oct 29, 2019
@yangning1368 @intel-mediadev
[Decode] add decode histogram #1
d9d85ee 
Change-Id: Ibaffb10cfc10ca7128e241804f2281323202fe13
@seaside1 seaside1 mentioned this issue Dec 27, 2019
Closed
@fulinjie fulinjie mentioned this issue Jan 14, 2020
Closed
intel-mediadev pushed a commit that referenced this issue Feb 11, 2020
@habuzaina @hanlong1
[VP] mhw changes
2bcdd10 
mhw changes #1

Change-Id: I5c6243ee48aa608531b2c1e966308868747dad88
intel-mediadev pushed a commit that referenced this issue Feb 11, 2020
@habuzaina @intel-mediadev
[Encode] SVN Backmerge - Encoder codechal changes
6de2414 
SVN Backmerge - Encoder codechal changes #1

Change-Id: I67188ff41e483925c630f414eeb2dd23078dd7ce
@feiwan1 feiwan1 mentioned this issue Apr 13, 2020
Closed
@ykku16github ykku16github mentioned this issue Apr 14, 2020
Closed
@fredvb fredvb mentioned this issue Jul 12, 2020
Closed
@heitbaum heitbaum mentioned this issue Dec 8, 2020
Closed
@XinfengZhang XinfengZhang mentioned this issue May 17, 2021
Closed
@HeJunyan HeJunyan mentioned this issue Jul 19, 2021
Closed
@ajgnet ajgnet mentioned this issue Sep 19, 2021
Open
@nirik nirik mentioned this issue Oct 30, 2021
Open
@aniketor aniketor mentioned this issue Nov 23, 2021
Closed
@ghost ghost mentioned this issue Nov 28, 2021
Closed
@SiewHoon SiewHoon mentioned this issue Nov 29, 2021
Closed
@jankratochvil jankratochvil mentioned this issue Dec 4, 2021
Closed
@zrus zrus mentioned this issue Jan 6, 2022
Closed
@ChuckPa ChuckPa mentioned this issue May 28, 2022
Closed
@xhaihao xhaihao mentioned this issue Mar 20, 2023
Closed
@zhangyichix zhangyichix mentioned this issue Jun 8, 2023
Merged
@zenaan zenaan mentioned this issue Nov 25, 2023
Open
@okfujian okfujian mentioned this issue Feb 20, 2024
Open
@fti-npawar fti-npawar mentioned this issue Jun 26, 2024
Open
@fenhu fenhu mentioned this issue Oct 11, 2024
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@uartie @oliver-sang